"checkout and reset do completely different things when given files or when not given files. reset on files should really have been called unadd. reset on refsp

"checkout and reset do completely different things when given files or when not given files. reset on files should really have been called unadd. reset on refspecs should really have been jumpto, moveto or something else indicative that the current branch ptr is moved to a new refspec. --soft and friends could have been --no-update-index or --no-update-files." I can understand your confusion, given the seemingly separate use cases for reset, but in fact, it makes perfect sense. Reset always does what it says it does. Let's break it down: git reset --mixed <commit> will make your current HEAD point to <commit>, reset the index to <commit>, and leave your working tree alone. This is useful for "uncommitting" the last commit, e.g. so you can split it up into smaller commits. Example: git commit -am "lots of changes" # realize you should really do better git reset --mixed HEAD~1 git add myfile.py git commit -m "implemented feature x" git add yourfile.py git commit -m "bugfix #3182" Handy. Now let's look at the "unadd' scenario: git add dontstage.py git reset HEAD dontstage.py == git reset --mixed HEAD dontstage.py, since --mixed is the implicit default git doesn't touch your commits, since you are already on HEAD. Git does reset the index to HEAD, which is before you added dontstage.py. If you had other changes that you added, it won't reset those, since you provided the limiter of dontstage.py. Git does not touch your working tree, so dontstage.py stays modified. The end result? Your working tree, index, and commits look exactly like before you ran git add dontstage.py. Now, if someone (e.g. easy git: http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/) wants to make git reset HEAD to unadd, that's fine by me. I'm speculating here, but I imagine that the Linus/git dev point of view is, why call it anything other than exactly what it is? It's just nice and elegant that it happens to suffice multiple use cases. The more you get into git, the more you start to realize why some of the commands that seemed arcane in the beginning are simple and elegantly named.