Re: [RFC/PATCH] mergetool: use resolved conflicts in all the views

[Seth House <seth@eseth.com>]

I appreciate Felipe getting the discussion started.

On Wed, Dec 16, 2020 at 02:24:23PM -0800, Junio C Hamano wrote:
> If there is none, then what is the benefit of doing the same thing
> without running 3 checkout-index?

I wasn't aware of this plubming when I wrote the initial shell-script
version of the technique. This is a much better approach (even *if*
there's a negligible performance penalty). This nicely avoids
UNIX/Windows line-ending surprises, and instead leans on
already-configured Git defaults for those. Plus the non-text files
benefit you mentioned is also huge.

> as I understand "mergetool" is handed an
> already conflicted state and asked to resolve it, it would not be
> possible without at least looking at the stage #1 to recover the
> base for folks who do not use diff3 style.

I feel strongly that LOCAL, REMOTE, and BASE should be left intact for
this reason, Also because they aid readers in understanding the
pre-conflicts versions of the file.

Rather mergetools (that support it) should be given the stage 1-3
versions of the file in addition to the usual, unmodified, above three.
Then each tool can decide whether or how to show each. Some graphical
tools might be able to make effective use of all five (six?).

(Feedback & other ideas are very welcome.)