On 14/03/2013 16:56, Junio C Hamano wrote:
Kevin Bracey <kevin@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html