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