Re: feature suggestion: optimize common parts for checkout --conflict=diff3

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2013, 21:50 UTC
Message-ID: <7vip54p58p.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130306212140.GA30202@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> I think Uwe's example shows that it _is_ useful. Yes, you no longer have
> the information about what happened through 1-14 (whether it was really
> there in the ancestor file, or whether it was simply added identically).
> But that information might or might not be relevant.

I think it is more like "I added bread and my wife added bread to our common shopping list" and our two-way "RCS merge" default is to collapse that case to "one loaf of bread on the shopping list". My impression has always been that people who use "diff3" mode care about this case and want to know that the original did not have "bread" on the list in order to decide if one or two loaves of bread should remain in the result.

> In Uwe's example,
> it is just noise that detracts from the interesting part of the change
> (or does it? I think the answer is in the eye of the reader).

In other words, you would use the "RCS merge" style because most of the time you would resolve to "one loaf of bread" and the fact that it was missing in the original is not needed to decide that. So, it feels strange to use "diff3" and still want to discard that information---if it is not relevant, why are you using diff3 mode in the first place? That is the question that is still not answered.