What is the point for git reset taking paths as an argument if we have git checkout?

Question

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

This happens all the time when people ask why they cannot 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 .

I never thought about it until I taught someone the difference between them.

Answer 1

As a rule, if you add a file to the index and understand that you want to remove it from the index, then you need:

• reference (HEAD) to reset the file index in HEAD (because HEAD refers to a state in which nothing has been done: commit)
• file

I.e:

  git reset HEAD -- a/file 

This will cause the file to be "disabled".

• git reset moves HEAD without affecting the contents (unless you do git reset --hard : the only mode the working tree affects)
• git checkout always changed the working tree (and the contents of the file)

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

For more on this topic, see What is the Difference Between ' git reset ' and ' git checkout '? "