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.
