On Wed, Mar 06, 2013 at 01:32:28PM -0800, Junio C Hamano wrote: > > We show "both sides added, either identically or differently" as > > noteworthy events, but the patched code pushes "both sides added > > identically" case outside the conflicting hunk, as if what was added > > relative to the common ancestor version (in Uwe's case, is it 1-14 > > that is common, or just 10-14?) is not worth looking at when > > considering what the right resolution is. If it is not worth > > looking at what was in the original for the conflicting part, why > > would we be even using diff3 mode in the first place? > > I vaguely recall we did this "clip to eager" as an explicit bugfix > at 83133740d9c8 (xmerge.c: "diff3 -m" style clips merge reduction > level to EAGER or less, 2008-08-29). The list archive around that > time may give us more contexts. Thanks for the pointer. The relevant threads are: http://article.gmane.org/gmane.comp.version-control.git/94228 and http://thread.gmane.org/gmane.comp.version-control.git/94339 There is not much discussion beyond what ended up in 8313374; both Linus and Dscho question whether level and output format are orthogonal, but seem to accept the explanation you give in the commit message. Having read that commit and the surrounding thread, I think I stand by my argument that "zdiff3" is a useful tool to have, as long as the user understands what the hunks mean. It should never replace diff3, but I think it makes sense as a separate format. I was also curious whether it would the diff3/zealous combination would trigger any weird corner cases. In particular, I wanted to know how the example you gave in that commit of: postimage#1: 1234ABCDE789 | / | / preimage: 123456789 | \ | \ postimage#2: 1234AXCYE789 would react with diff3 (this is not the original example, but one with an extra "C" in the middle of postimage#2, which could in theory be presented as split hunks). However, it seems that we do not do such hunk splitting at all, neither for diff3 nor for the "merge" representation. -Peff -- 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