Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > after these commands: > > $ git init > $ mkdir subdir > $ echo a > subdir/a > $ git add subdir/a > $ git commit -m a > $ echo more a >> subdir/a > $ echo b > subdir/b > $ git add subdir/* > $ git commit -m b > $ git checkout HEAD^ -- subdir > > I'd expect that subdir/b is removed from the index as this file didn't > exist in HEAD^ but git-status only reports: > > # On branch master > # Changes to be committed: > # (use "git reset HEAD <file>..." to unstage) > # > # modified: subdir/a > # > > Is this intended? > > (I'm using git 1.8.4.rc3 as shipped by Debian (package version > 1:1.8.4~rc3-1).) The intended behaviour of "git checkout tree-ish -- pathspec" has always been "grab paths that match pathspec from tree-ish, add them to the index and check them out to the working tree". If you have subdir/b in the index and the working tree, it will be kept when the paths that match "subdir" pathspec is grabbed out of the tree-ish HEAD^ (namely, subdir/a) is added to the index and to the working tree. I could argue that the above intended behaviour is suboptimal and it should have been "the resulting paths in the index and the work tree that match the given pathspec must be identical to that of the tree-ish". In the resulting index or working tree, paths that match "subdir" pathspec in the above result is subdir/a and subdir/b, and that is different from what exists in the given tree-ish (which has only subdir/a and not subdir/b), and under that modified definition, what the current one does is not correct. I vaguely recall arguing for the updated behaviour described in the above paragraph, and I even might have started working on it, but I do not think we changed this behaviour recently, unfortunately. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html