Here is what
git checkout treeish -- file does:
$ git init foo $ cd foo/ $ echo aaaa > file.txt $ git add file.txt $ git commit -m 'commit aaaa' $ git checkout -b bbbb $ echo bbbb > file.txt $ git add file.txt $ git commit -m 'commit bbbb' $ git checkout master $ git checkout bbbb -- file.txt $ cat file.txt bbbb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: file.txt
file.txt has not only been modified to contain
bbbb, but this change has also been added to the index.
Yet the man page states:
DESCRIPTION Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch. ... git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>... When <paths> or --patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit). In this case, the -b and --track options are meaningless and giving either of them results in an error. The <tree-ish> argument can be used to specify a specific tree-ish (i.e. commit, tag or tree) to update the index for the given paths before updating the working tree.
The man page talks only about 'working tree' and states nothing about updating the index.
I don't understand the inconsistency.
Is the executable or the man page incorrect? ... or is there some missing assumed magic git knowledge that I lack?