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

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.


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

Reply via email to