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

From: Jeff King <peff@peff.net>
Date: Sep 19, 2013, 07:46 UTC
Message-ID: <20130919074616.GA29773@sigill.intra.peff.net>
In-Reply-To: <xmqqd2o7w0xc.fsf@gitster.dls.corp.google.com>

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

Show 11 quoted lines

> 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