Every time a file has been staged, Git offers helpful instructions in the event you needed to unstage a file:
(use "git reset HEAD <file>..." to unstage)
However the decent Git Tutorials by Atlassian simply say:
git reset <file>
This seems more straightforward, so why the difference?
No difference (from
git reset
man page) in term of default parameter:That message initially did not include HEAD: commit 3c1eb9c, Jan. 2007, git 1.5.0-rc1, but since the default is not always known, the help message makes it clear to which commit you are supposed to reset.
HEAD
appears in commit 367c988, Nov. 2007, Git 1.5.4:torek points out an actual difference in the comments:
See more on the double hyphen syntax (
--
) in "Deleting a badly named git branch".The OP skube adds in the comments:
While
git reset
man page clearly indicates the lack of tree-ish ingit reset <tree-ish> -- <paths>
means HEAD, it is not so forgit checkout <tree-ish> -- <paths>
.That means
git checkout -- path
will override the working tree with what has already been staged (git add
'ed).While
git reset -- PATH
(being the mixed form of git reset) will reset the index with what HEAD contains (effectively un-staging what was added)git reset
andgit checkout
don't use the same default, and:git reset <tree-ish> <file>
:HEAD
.Hence
git reset HEAD <file>
;git checkout
: it is the index.Hence
git checkout -- file
.The
--
has to be used in thegit checkout
case, since there is only one parameter, and it needs to be clear that parameter represents files.Note that
git checkout HEAD files
is different: torek mentions in the commentsNote: with Git 2.23+, August 2019, you might use
git restore
insteadSee the examples:
man page:
git restore --staged hello.c
does not specify a source, and restore the index only (--staged
): it does so (by default) using HEAD as source.Other examples:
git restore
is a more natural command name, and has no ambiguity.