On Thu, Mar 07, 2013 at 10:40:46AM -0800, Junio C Hamano wrote: > Where we differ is if such information loss is a good thing to have. > > We could say "both sides added, identically" is auto-resolved when > you use the zealous option, and do so regardless of how the merge > conflicts are presented. Then it becomes perfectly fine to eject > "A" and "E" out of the conflicted block and merge them to be part of > pre/post contexts. The same goes for reducing "<C|=C>" to "C". As > long as we clearly present the users what the option does and what > its implications are, it is not bad to have such an option, I think. Exactly. I do think it has real-world uses (see the example script I posted yesterday), but it would never replace diff3. I'm going to try it out for a bit. As I mentioned yesterday, I see those sorts of cherry-pick-with-something-on-top conflicts when I am rebasing onto or merging my topics into what you have picked up from the same topic on the list. I think the code in Uwe's patch looked fine, but it definitely needs a documentation change to explain the new mode and its caveats. I'd also be happy with a different name, if you think it implies that it is too related to zdiff3, but I cannot think of anything better at the moment. > > The wrong thing to me is the arbitrary choice about how to distribute > > the preimage lines. > > Yeah, but that is not "diff3 -m" vs "zealous-diff3" issue, is it? > If you value the original and want to show it somewhere, you cannot > avoid making the choice whether you are zealous or not if you split > such a hunk. Right, but I meant that we would never split a hunk like that with diff3, because we would not do any hunk refinement at all. Splitting a hunk with "merge" is OK, because the "where does the preimage go" problem does not exist there. zdiff3 is the only problematic case, because it would be the only one that (potentially) splits and cares about how the preimage maps to each hunk. But we can deal with that if and when we ever do such splitting. -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