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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 18, 2020, 10:04 UTC
Message-ID: <xmqq3603v3a0.fsf@gitster.c.googlers.com>
In-Reply-To: <20201218054947.GA123376@ellen>

Seth House <seth@eseth.com> writes:

Show 26 quoted lines

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