Jeff King <peff@xxxxxxxx> writes: > I didn't look too deeply at your example, but I suspect it may be > related to the fact that diff3 does not try to minimize the conflicts as > much (and then the recursive merge on top of that piles on extra layers > of confusion). > > There's a lot more discussion in this old thread: > > https://lore.kernel.org/git/20130306150548.GC15375@xxxxxxxxxxxxxx/ Yes, it does not help that the given sample involves conflicts in the inner merge, which is unfortunately almost unreadable. For less confusing merges, diff3 style is often a lifesaver necessary for avoiding mismerges by showing what the common ancestor looked like, so that the reader/merger/integrator can tell what each side wanted to do to the conflicted section. Rejecting diff3 style output because of the way a conflicted part in the inner merge appears as a common ancestor version may be throwing the baby out with the bathwater. A different way to say it is that until we improve the way the conflicted inner merge is shown, diff3 style is not something we can recommend to new users as a default, I would think.
