From: Jeff King <peff@peff.net>
Date: Tue, 17 Sep 2013 20:29:17 GMT
Subject: Re: [BUG?] git checkout $commit -- somedir doesn't drop files
Message-ID: <20130917202917.GA20020@sigill.intra.peff.net>
In-Reply-To: <xmqq61tzxkgz.fsf@gitster.dls.corp.google.com>

On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:

> 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?

Hrm. Probably not. It is almost a one-way merge going to the named tree
(but limited by the pathspec), except that I think the current
git-checkout code may provide some safety checks related to where we are
coming from (e.g., do we unconditionally overwrite entries that are not
uptodate?).

-Peff