Re: [BUG?] git checkout $commit -- somedir doesn't drop files
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 17, 2013, 20:27 UTC
- Message-ID
- <xmqq61tzxkgz.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20130917201259.GB16860@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 14 quoted lines
> 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?
Show 8 quoted lines
>> 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