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

From: Seth House <[email-masked]>
Date: Thu, 17 Dec 2020 02:44:24 -0700

On Thu, Dec 17, 2020 at 08:35:21AM +0100, Johannes Sixt wrote:
> Where's WinMerge in your list?

Added. Thanks for the suggestion; I wasn't familiar with it. Let me know
if I missed anything in my (quick) assessment. The "auto-merge" function
does indeed produce similar results to Felipe's patch.

> I would say that this is a hint that post-processing should
> be moved to the tool drivers, and should not be done at the proposed level.

That was my thought as well and it didn't occur to me to raise
a discussion here. However Felipe made the good point that adding this
functionality in upstream Git would have immediate downstream effects
for most tools. Almost every mergetool I've surveyed so far simply
blindly shows a diff betweeen LOCAL and REMOTE (and sometimes BASE and
sometimes MERGED) and Felipe's patch would have an immediate benefit for
all those tools.

There are a few notable exceptions that have their own, internal
conflict resolution logic -- tkdiff, WinMerge, and (I think) IntelliJ.
And only two tools make direct use of the conflict resolution that Git
already performed to produce MERGED -- Emacs+Magit, and diffconflicts.
Those tools would have to make a decision whether to opt-in to the
autoMerge flag or not.

I did not initially like Felipe's patch because I personally want my
mergetool to use all five of LOCAL, REMOTE, BASE, _and_ the two split
halves of MERGED. However the pragmatism of it is growing on me. Because
so many mergetools do simply diff LOCAL and REMOTE this one, simple
opt-in would positively benefit all of them.