Re: Handling merge conflicts a bit more gracefully..

From: Junio C Hamano <junkio@cox.net>
Date: Jun 9, 2005, 05:15 UTC
Message-ID: <7vzmu0t8j5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.58.0506082145160.2286@ppc970.osdl.org>

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

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

>> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> 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.

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