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

[Jeff King <peff@peff.net>]

On Tue, Sep 17, 2013 at 03:14:39PM -0700, Junio C Hamano wrote:

> Yeah, then I agree that "git checkout HEAD^ -- subdir" should be a
> one-way "go HEAD^" merge limited only to the paths that match
> subdir/.
> 
> If implemented in a straight-forward way, I suspect that we may end
> up not removing subdir/b in Uwe's sample transcript. I am not sure
> if that is a good thing or not, though.  If the index originally
> tracked and then "going to" tree does not, I think removing it would
> match "ignore local modifications" rule, as subdir/a that is tracked
> in the index and also in "going to" tree does get overwritten to
> match the state recorded in the tree.

I had assumed the goal was to subdir/b (by the reasoning above, and the
"rm -rf && tar" analogy you gave earlier).

I tried a very hacky attempt at shoving unpack-trees into the right spot
in checkout_paths. But its pathspec handling from unpack_trees is not
quite what we want.

In Uwe's case, it did delete subdir/b and overwrite subdir/a, which I'd
expect. But if there was an additional file outside of subdir, it got
deleted, too.  The problem is that I was giving the regular index to
unpack_trees as the destination; so it wrote out only the bits of the
index under the pathspec subdir/, and omitted the rest entirely. I had
hoped instead it would leave those parts untouched from the source.

An alternative would be to write the new entries to a temporary index
in memory. And then you can throw away the entries in the current index
that match the pathspec, and add in the entries from the temporary
index. I was just hoping that unpack-trees would do all of that for me.
:)

At this point, I'm giving up for now. I was hoping a naive application
of unpack-trees would just work (and reduce the code size to boot), but
it is obviously a bit more complicated than that. I still think it's a
good idea for checkout to behave as Uwe described, but I don't think
it's that high a priority, and I have other stuff I'd prefer to work on
at the moment.

-Peff