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

[Kevin Bracey <kevin@bracey.fi>]

On 14/03/2013 16:56, Junio C Hamano wrote:
> 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