> Staged: The current version of the modified file is staged to be included in the next commit.
A bit of a nitpick, but if I change a file, "git add" it, and then change it again, both of these statements are false.
Of course, the workaround there is that one adds the initial file into the staging area and then `git add -p` the subsequent changes. It could just be a bit more convenient on that front, is all.
> In Git, a change in a file, can be in one of these three states: unstaged, Staged, Committed
They create commits from scratch from the command line--manually creating each /.git/ file with shell commands and a text editor. Really fun talk. Would highly recommend it for people who were planning on learning about git internals at some point.
[0] "How does Git actually work? - CB Bailey & Andy Balaam [ACCU 2019]"
Thank you.
Don’t get me wrong. I think articles like these help a lot to demystify git and I believe it makes the tool easier to use and reason with when one knows what it does. But why is nobody finding or reading the later chapters in the docs?
> But why is nobody finding or reading the later chapters in the docs?
I think to read the latest chapter of a book, one usually needs to read the earlier ones too. I personally don't jump directly to the internals when I want to read about something, because I'd then assume I am missing a lot of context and background.
Because most people don’t ever read the book period. 90% of users follow a basic tutorial or instruction sheet to get the five commands they’ll use by rote and go no further.
And, separately, the internals section of the book are mostly uselessly shallow, so if you start digging into that you quickly forget that the book even has one such section.
https://github.com/grantm/no-more-f-s-repo
Parental Advisory: Contains strong language.
On the topic, I'm just going to plug the tool git-branchless. Completely transformative for my use of git at work. Stacked commits that actually work!
https://github.com/arxanas/git-branchless/wiki/Concepts#anon...
> Normally, only commits which are reachable by a branch are visible in stock Git.
But this is not true: a "soft" tag suffices to keep a pseudo-branch visible to, say git-log --graph. In my own workflow, I've let these replace temporary branches proper.
I think there may be an error around the "git write-tree" step. That or I did something wrong.
Here's my user test: https://www.youtube.com/watch?v=bul4CPRkv6c
Now, I've found a utility (made by my brother who shared it with me a few days ago and I told him to opensource it since I liked it soo much) that handles all the formatting and rewriting for me. I just write my commits, and it takes care of the rest.
Here's a video demonstrating this magic (though it's for rsync): [asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1](https://asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1).
Check out the utility here: [github.com/zerocorebeta/Option-K](https://github.com/zerocorebeta/Option-K).
I edited my original post to reflect this
