Re: Handling merge conflicts a bit more gracefully..

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

LT> On Wed, 8 Jun 2005, Junio C Hamano wrote:

quoted

quoted

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

LT> Yeah, ok, so the fact that we allow missing things in the
LT> index (which was debatable to start with) makes for
LT> exceptions.

quoted

Not just that.  Another big difference is that we allow _extra_
things in the index in two-tree case (i.e. local additions).
But I do not think these exceptions are necessarily bad.

LT> Well, they'd be bad in a three-way merge.

No question about it.  I am not proposing to conditionally
accept extra entries in 3-way case.

But when "read-tree -m H I-mixed-with-H M" 3-way merge is
emulating "read-tree -m H M", it does not need to accept any
extra entries in the cache, because in this case "our head" tree
is "I-mixed-with-H", which by definition contains everything in
the current cache (remember, "I-mixed-with-H" is built by
looking at each path and if it has stage0 then copy it to stage2
otherwise if it has stage1 then copy it to stage2, after reading
the index file into stage0, H into stage1, and M into stage 3).

And after such "3-way merge emulating 2-way fast-forward," you
can commit---the commit will have a single parent, M, and the
difference it contains is the changes the user made while he was
working off of H, rebased to M.

Of course this all assumes that we have a perfectly working
three-way merge ;-).