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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Dec 17, 2020, 10:35 UTC
Message-ID: <5fdb3471c6bb7_d6d032087@natae.notmuch>
In-Reply-To: <20201217094424.GA75257@ellen>

Seth House wrote:

Show 24 quoted lines

> 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.

Each tool would have to be evaluated individually, but at least from what I can see your tool--diffconflicts--shows exactly the same diff with or without my patch, and the `mergetool.automerge` configuration. It's only the DiffConflictsShowHistory command (which is secondary functionality, that you didn't even mention in your blog) that gets affected.

So, yes; *some* behavior is affected, but in my opinion not in a negative way.

In my view the whole point of "git mergetool" is to resolve conflicts, so if git can resolve conflicts *before* launching the mergetool, it should (whether it's rerere or automerge).

Show 5 quoted lines

> 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.

Yes. But other people may want to see the secondary functionality of your DiffConflictsShowHistory command with simplified conflicts, and those people can enable the option.

If you want to see the original LOCAL, REMOTE, and BASE, you can turn off that option (or simply never turn it on).

With the option everyone can have what they want.

I for example can keep using `gvimdiff3`, except with simpler diff chunks, thanks to your idea.

And for the record; "git mergetool" is one of of those things that you setup once, and forget about it. My fingers have been trained for more than a decade (maybe two) on exactly the same configuration, and I initially didn't think you were onto something.

It's really good that you did setup a test repository with a merge conflict that showcased the different situations one might encounter. It immediately became clear to me that you were indeed onto something.

So I give you full credit for the idea, and explaining it succinctly, that's in the commit message. I just found a way to shove it directly into "git mergetool".

Cheers.

-- 
Felipe Contreras