> Unlike many tools, it is easier to understand the internals of git than the externals.
But why should that be? For example, the git docs use different terms for the same thing (e.g. cache, index, stage).
Also, the git tools overload the same command for different purposes (e.g. git add tracks new files or stages pending changes from existing files; git reset can unstage pending changes or revert committed changes). These are different functional procedures that happen to share implementation details.
Don't use "git reset" to revert committed changes. Well... do, but be careful... The word "revert" is problematic here, and I suppose that "reset" is a bit awkward, too.
In git, a "revert" means you are creating a new commit that is the reverse of the commit you want to undo. The two commits exist and effectively cancel each other out. The danger here is potentially thinking "git reset" will revert a committed and pushed change (sometimes people push early). In general, this is probably not what you intend.
"git reset" moves branch pointers around. So when you "git reset HEAD^", you are really saying you want to move your current branch and HEAD (the thing that indicates where you are in the tree) to the prior commit. The current commit still exists but can be ignored.
Speculation now, but I think it is right... This same understanding applies to the "unstaging". The staging area is another tree node, and when you say "git reset HEAD" on the staged file, you are moving it back into the HEAD state.
One note on unstaging and other resetting... You can reset --soft or --hard. --soft (default) means that you want to dirty up your directory with the differences between the file's current revision and the reset revision. This is useful if you are cleaning up an unpublished branch (using reset to undo).
"git reset" could be called "git move-my-branch-tag" and make more sense.
btw, the term "revert" has a pretty standard usage in most version control software, including Subversion, Mercurial, Perforce, Bazaar, Darcs, Monotone, Fossil, and AccuRev. Why did git not only invent a new term for discarding uncommitted changes, but reuse "revert" to mean something different?
Good question for the devs. "git apply-reverse-patch" was probably too long for a fairly common operation? I suppose when you are trailblazing with a new paradigm, you are allowed to redefine things. I don't let those kinds of things bother me, personally; I just adapt my thinking to the new thing I am learning. Helps me to learn new languages easier.
It's kind of a silly guessplanation, but I have a feeling that Linus Torvalds made the call and it stuck. I don't know anything about the people who actually maintain Git, though.
But why should that be? For example, the git docs use different terms for the same thing (e.g. cache, index, stage).
Also, the git tools overload the same command for different purposes (e.g. git add tracks new files or stages pending changes from existing files; git reset can unstage pending changes or revert committed changes). These are different functional procedures that happen to share implementation details.