Great article. Just one rather glaring omission: only a single mention of the index, and that only in passing. I have used git for years, and I still don't understand what the fleeping index is supposed to be for. What can you do with the index that you can't do with a branch? And why is it called the index? (And why is it git add -a but git commit -A? Or maybe it's the other way around?)
Not to be cruel, but I don't understand how you've used Git for years without understanding what the index is. There's more than a few learning resources for Git online to satisfy your curiosity. Anyway, to give an abbreviated explanation:
The index is a staging area for your commits. When you use `git add`, changes in the working directory are staged (prepared) for the next commit. If you pass the `-a` flag to `git commit`, Git will stage all changes to files that it is already aware of. (Recall that new files are untracked and must be manually added to the index the first time they're committed; `-a` won't add those files because Git doesn't already know about them.)
Why have a staging area instead of just creating a commit directly from all the changes in the working directory? It's basically a sanity measure for organizing commits if you're ever anything less than a perfect developer. If you make a bunch of changes and later realize that there's more than one "unit of work" represented in those changes (however you choose to define those units), you can selectively add files to the index to create commits that make sense. You can even use the interactive mode of `git add` to selectively stage changed sections within a single file. If you care about the benefits of sensible commits -- bug hunting with bisection, ability to run `git revert` to undo a logical unit of work -- then the index is your friend.
Well, I'm being a little facetious. I do understand what the index is and what it's used for (but not why it's called the "index" instead of, say, the "stage"). What I don't understand is why the index exists as a separate abstraction. You could have the exact same effect by, for example, doing a git stash, and then popping changes out of the stash into your (now clean) working directory. The WD in effect plays the role of the index, and you get the same result, but with fewer abstractions, fewer commands, and less confusion.
But I hold Linus in high enough regard to take very seriously the possibility that the index is a reflection of some deep wisdom that I have missed. That's the real reason I raise this every now and again.
I'm not sure I see how you could use `git stash` to accomplish the same thing. Running `git stash && git stash pop` is almost a no-op, so you don't get the benefits described above. Am I missing something?
I thought you could pull individual files out a stash, but it seems I was wrong about that. But it's not hard to imagine a variation of git stash that allowed you to select individual files from a stash to pull back into your working directory.
