Why does "git checkout <filename>" only work for non-staged files?

Question

If I commit and then make changes to a file foo, I can undo these changes by git checkout foo. If I make changes to foo AND add them with git add foo, then git checkout foo doesn't do anything (and doesn't say anything)

What is the reasoning behind this?

Answer 1

With Git 2.23 (August 2019), you now can avoid using the confusing git checkout command (which deals with files or branches), and the new (still experimental) git restore command.

You can restore both the index and the working tree (this the same as using git-checkout)

git restore --source=HEAD --staged --worktree hello.c

or the short form which is more practical but less readable:

git restore -s@ -SW hello.c

That will restore both working tree and staging area (cache).

Answer 2

When you say

git checkout foo

without additional arguments, you're telling git to replace the foo in your worktree with the foo in your index. So if you've added (i.e. staged, i.e. updated the index with) all the changes to foo, then of course there's nothing for this checkout command to do.

The normal procedure to back out the change would be to first reset (update the index from the HEAD commit) and then use checkout to update the working version.

Then again, you can use checkout to get the version of foo from the previous commit

git checkout HEAD foo

This works just as well; the two-step approach is probably just a bit more widely known since it uses commands suggested by git status for un-staging and un-doing changes.

Answer 3

Because you can unstage it and then check it out :)

git reset <file>

git checkout <file>

The reason behind not checking them out as well is because if you change your files locally and then want to update to the master branch in example, your work and staged files should be overridden.