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

[Junio C Hamano <gitster@pobox.com>]

Seth House <seth@eseth.com> writes:

> On Thu, Dec 17, 2020 at 08:49:13PM -0600, Felipe Contreras wrote:
>> And no person is the sole arbiter of truth, in this list, or anywhere.
>> People have managed to change Junio's mind.
>
> I'm not worried about Junio but I am wondering if anyone has managed to
> change your mind. You and I have been going back and forth on this list
> and on Reddit for two solid days and, to be frank, I'm running out of
> steam.
> ...
> I, as a user of diffconflicts, may want to both disable this flag for
> diffconflicts but enable this flag for VS Code and kdiff3. It is not
> unusual for people to use more than one mergetool. Some of them are
> better or worse at visualizing different kinds of conflicts. Sometimes
> a conflict is small and straightforward; othertimes a conflict is
> complicated and requires deep knowledge of the history of both branches.
> If we force this to be a global flag only then users will not be able to
> make different choices for different tools.
>
> Someone who does use multiple mergetools but only uses tools from group
> one may appreciate a single global flag so s/he doesn't need to set it
> for each tool.
> ... there's every possibility that a user will prefer it a different
> way or that a mergetool author will. And there's every possibility that
> there will be differing opinions between users and authors like there is
> between you and me. But that's ok! Because it's just a configuration
> option.

Well explained.  I do not think I need to add much.

It makes sense to at least allow people to enable/disable the
behaviour independently for different tools.  When unconfigured, I
would say we should enable the feature by default to give it wider
exposure.

Because what I care is not about the set of tools we happen to have
right now, but is about leaving users access to an escape hatch in
case things go wrong.  If it turns out that all the tools we happen
to have do not seem to break with this new option with just a few
days' survey, it does not mean we do not need a per-tool escape
hatch they can use until the next release either fixes the feature
or makes it disabled by default, when there is unexpected breakages
discovered later.  The time between a release and the next is a long
time that the users cannot keep the tool they have learned to rely
on broken.  And that's a conservative maintainer's view.

When a tool that never wants its input munged appears, we might
further want to have the mechanism to give different default per
each tool for users who have no configuration, so that such a tool
can be disabled while other tools are enabled by default while
allowing users to choose.  But such a code to set different
enabled/disabled default per tool (the one I outlined in the
footnote of the other message) won't be exercised in practice with
the set of tools we have (hence a bug in such a code would go
unnoticed for a long time), so I tend to think we might be better
off to wait until the need arises before implementing per-tool
fallback default for users who do not configure at all.

Another reason why allowing users to disable the feature per tool is
important is because as far as I know we have kept the mergetool
framework to allow adding a tool that can merge binary data, and
leaving these three files pristine was one ingredient for that.
With only a single knob, we would be making a decision to declare
that such a tool is unwelcome, which is not quite acceptable.  I
expect that users would want the new feature most of the time
because they would be managing text files more of the time, and
having only a single knob would force an unnecessary choice on those
who want to use such a binary-capable tool as well.