4

I understand git reset updates the index, whereas git checkout updates the working copy. What I don't understand is the use case that requires git reset to accept an argument for reference and path? It seems I would always want to use git checkout in this case?

This comes up all the time when folks ask why they can't git reset some-ref --hard -- some/path/to/file. The real question is why git reset even accepts git reset some-ref -- some/path/to/file when we have git checkout.

Never thought of this till teaching someone the difference between the two.

kayaker243
  • 2,580
  • 3
  • 22
  • 30
  • This is more of a "my impression" than an "answer" (hence as a comment), but: git is full of redundant ways to do things, I think largely as a consequence of organic growth. That's one of the things that really confuses newbies, there are 5982 ways to do X, a bit over half of them being bad ideas for some reason, most of the remainder being klunky, and three of the best ones being clean and simple with no reason to choose one over another. :-) – torek Aug 08 '13 at 00:50
  • what about unstaging changes? `git add somefile.txt`, *woops*, `git reset somefile.txt`. – Gabriele Petronella Aug 08 '13 at 02:36
  • @GabrielePetronella yeah, but that use case isn't the question. the question is resetting the index for some file path to a previous commit. – kayaker243 Aug 08 '13 at 20:30

1 Answers1

1

Typically, if you add a file to the index, and realize you want to remove it from the index, that is where you need:

  • a reference (HEAD) to reset the file index to HEAD (since HEAD reference a state where nothing has been staged yet: a commit)
  • a file

That is:

 git reset HEAD -- a/file

That would "unstage" a file.

  • git reset moves HEAD without affecting the content (unless you do a git reset --hard: the only mode where the working tree is affected)
  • git checkout always modified the working tree (and the file content)

git reset accepts a ref and a path because it has three modes (soft, mixed and hard).
(see also "Practical uses of git reset --soft?")
Only the --hard mode is similar to git checkout.

More on that same topic in "What's the difference between 'git reset' and 'git checkout'?".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Yeah, I see the point of using it with a HEAD ref, but that's the only one I could think of. – kayaker243 Aug 08 '13 at 20:31
  • @kayaker243 no, you can also used it to revert a file to any commit you want (with `--hard`). Or to redo a merge (`--soft` where you just move the HEAD, without touching the index or working tree, as I mention in [Practical uses of git reset --soft?](http://stackoverflow.com/a/5203843/6309)). In both cases, you would use a commit, not just 'HEAD'. – VonC Aug 08 '13 at 21:11