It is also really absurd that you can reset everything with `git reset --hard` but you have to use `git checkout -- ` to reset individual files. It's not even clear why `checkout` is involved in resetting files at all.
git-reset - Reset current HEAD to the specified state
git-checkout - Switch branches or restore working tree files
checkout works primarily (in the case of checkout <pathspec>) to copy file from somewhere (commit, index) into the working tree. You can use checkout to mimic a hard reset: `git reset --hard` is pretty much equivalent to `git checkout HEAD .`
Nobody really needs to know about `reset --hard`, the same effect can be achieved with a normal reset and a checkout, it's a two step process anyway, regardless of how you do it.
Using reset+checkout is not the quickest but gets the job done. Power users can create themselves a shell alias, or write themselves a small shell script, or learn about one of the thousands commandline switches that does just what they need.
`git checkout -- <file>` checks out the HEAD version of a given file.
A:
`git reset --hard` checks out the HEAD version of your worktree.
`git checkout -- <file>` checks out the HEAD version of a given file.
B:
`git reset --hard` resets your worktree to the HEAD state.
`git checkout -- <file>` resets a file to the HEAD state.
I don't think a newbie could even grok the difference between these three descriptions.
git reset --hard HEAD
> I don't think a newbie could even grok the difference between these three descriptions.
This part is definitely true - Git offers only a very light abstraction on top of its data structures.
If there's something inconsistent about this, it's that it works for individual files, but (fortunately) not for clobbering your entire worktree by checking out a branch.