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

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

Jeff King <peff@peff.net> writes:

> But it would apply to the content that is outside
> of the hunk marker; we have changed the concept of what is in the base
> and what is in the conflict by shrinking the conflict to its smallest
> size.

Hmm, unless you mean by "base" something entirely different from "what was in the common ancestor version", I do not think I can agree. The point of diff3 mode is to show how it looked line in the common ancestor and what the conflicting sides want to change that common version into; letting the user view three versions to help him decide what to do by only looking at the part inside conflict markers.

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?