Re: [BUG?] git checkout $commit -- somedir doesn't drop files

[Junio C Hamano <gitster@pobox.com>]

Uwe Kleine-König  <u.kleine-koenig@pengutronix.de> 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.