Like, the question: "How do I undo 'git add'" shouldn't have over ELEVEN THOUSAND upvotes on StackOverflow: https://stackoverflow.com/questions/348170/how-do-i-undo-git...
That's just bullshit
If the last thing you did was stage, do you want to unstage, or undo the last change outside the staging area?
If undoing the last thing you did is not compatible with the current state of the working copy, what happens?
If your last change was to discard or apply uncommitted changes, how can that be undone? If the answer is "do lots of hidden commits", how does that interact with undo?
I totally understand why those were chosen when the original code for git was written but I really think it's time to re-evaluate the CLI and do better.
- Git stores snapshots, not changes.
- Snapshots go into something called an index. "Git add" means to add to an index.
- A new commit is prepared by creating a new index based on the index of the HEAD commit. This new index is the "stage". The index holds a complete copy of the files. When you stage only certain changes with "git add --patch", that is still the case: you're making a version of the file which has only those selected changes and that goes into the index. A built-in tool that is external to the git representation did the text manipulation to separate those changes.
- When you commit, the uncommitted index you have created as a stage becomes a commit.
Also I believe "git stage" exists too: https://git-scm.com/docs/git-stage
Because git commands are used in a bajillion scripts, it's very hard to remove "excessive" functionality from the old commands even when that would improve the orthogonality of the tools.
Git should eliminate the following redundant naming: stage, cache, index all refer to the same thing.
If I want to diff between the working copy and the stage, why isn't it "git diff --stage", but "git dif --cached"?
A cache is something for fast lookup; the index isn't a cache; it's the permanent record of stuff in version control that will become a commit.
When you invalidate a cache entry, the semantics is unaffected, only speed of access. Removing from a git index is semantically significant.
"Consider the expression 1/3 + 25. In PL/I this expression has the value 5.33333333333. Why? One-third is computed to 15 digits of precision, 14 to the right of the decimal point. Then 25 is coerced to the same precision, losing the most significant digit 2! This does raise an error in PL/I, but the default is to ignore it."