Jeff King <peff@xxxxxxxx> writes: > On Tue, Sep 17, 2013 at 01:27:08PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html