Jeff King <> writes:

> On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote:
>> Jeff King <> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to