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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 17, 2013, 20:40 UTC
Message-ID: <xmqq1u4nxjv2.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20130917202917.GA20020@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 27 quoted lines

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

I think we do unconditionally overwrite and that has been very much on purpose.

"git checkout tree-ish -- file.txt" has always been about replacing whatever cruft is in paths in the worktree that match pathspec, just like "cat content-created-elsewhere >file.txt" is. "Oops, you have a local change that do not match index" is the last thing we want to say, because getting rid of that local change is the primary reason why "checkout tree-ish -- file.txt" exists.

Taking the state of a subdirectory as a whole as "content", the change we are discussing will make it more like "rm -fr dir && tar xf some-content dir" to replace the directory wholesale, which I personally think is a good thing in the longer term.