From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 17 Sep 2013 20:27:08 GMT
Subject: Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Message-ID: <xmqq61tzxkgz.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20130917201259.GB16860@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Tue, Sep 17, 2013 at 12:58:07PM -0700, Junio C Hamano wrote:
>
>> 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.
>
> Our emails just crossed, but I basically ended up saying a similar
> thing.  Could we simply replace the "update_some" in builtin/checkout.c
> with a two-way merge via unpack-trees?

Would it work to resolve a conflicted index by checking out from a
known tree?

>> 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.
>
> Yes, I did some digging and I think it has always been this way, even
> before git-checkout was a builtin.
>
> -Peff