Re: [PATCH v3 3/3] git-merge-one-file: revise merge error reporting

From: Kevin Bracey <kevin@bracey.fi>
Date: Mar 14, 2013, 17:31 UTC
Message-ID: <5142097B.1080105@bracey.fi>
In-Reply-To: <7vr4jiyqrj.fsf@alter.siamese.dyndns.org>

On 14/03/2013 16:56, Junio C Hamano wrote:

Show 13 quoted lines

> Kevin Bracey <kevin@bracey.fi> writes:
>
>> Maybe the virtual base itself should be different. Maybe it should put
>> a ??????? marker in place of every unique line. So you get:
>>
>> Left   ABCEFGH
>> Right XABCDEFJH  -> Merge result <|X>ABC<|D>EF<G|J>H
>> VBase ?ABC?EF??H
>>
>> That actually feels like it may be the correct answer here.
> Interesting, though the approach has downsides with the diff3
> conflict style, no?
>

Well, yes, but I would assume that we would forcibly select normal diff here somehow, if we aren't already. We should be - turning ABCDEFGH vs ABCD into ABCD<EFGH|EFGH=> is silly.

This topic has a lot in common with the zdiff3 discussion going on. The concern there is about large chunks of similar code appearing on two sides, and not being in the base, leading to useless diff3.

This is just the special case of the base being totally empty.

The thought on zdiff3 philosophy was that common additions should be treated as resolved, and not appear inside conflict markers. That's exactly what we'd be doing. So, same conflict as above, but this time embedded in a larger file, using zdiff3 logic:

Left aaaaaabaacaaABCEFGHeee Base aaaaaaaaaaaaeee -> zdiff3 aaada<b|a=f>aacaaABC<|D>EF<G|J>Heee Right aaadaafaaaaaABCDEFJHeee

Note that I've chosen to suppress the = marker if the lines surrounding the conflict are not in the base. I think that helps highlight the fact that we're in a diff2 section. EF<G|=J>H reads like an assertion that the base has EFH. Whereas EF<G|J>H avoids that.

So, anyway, commonality with zdiff3 would be good. Even if we can't share code, we should at least share the general style of result.

Kevin