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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 19, 2020, 11:14 UTC
Message-ID: <xmqq1rfmqc8g.fsf@gitster.c.googlers.com>
In-Reply-To: <20201219001358.GA153461@ellen>

Seth House <seth@eseth.com> writes:

Show 12 quoted lines

> I think where we're not seeing eye-to-eye is that you're focusing on
> potential "negative" consequences whereas I'm talking about having more
> information about the merge rather than less.
>
> There is very likely no negative consequences for most, if not all,
> mergetools. I wrote the initial version of diffconflicts ten years ago
> and I've been using it nearly every day since. I'm fairly confident in
> the end result. What is a fact is there is undisputedly less information
> about the merge if we overwrite LOCAL and REMOTE; as I've written,
> I think the tradeoff is worthwhile for most tools but a per-tool
> configuration will allow people that feel differently to choose
> differently.

Thanks for stressing this point.

When a user or developer asks for a reasonable feature (e.g. configurability to suit personal taste), especially when there is no obvious downside for adding it, the burden of proof is on the party who refuses to add it---they are the ones who have to adequately explain why adding it is actively harmful, not just the proposed addition is not necessary [*1*].

There is no need for any "evidence" of "negative consequence" at all to ask for a way to selectively enable or disable a new feature. A new feature tends to trigger unexpected bugs in unseen corner cases more than an older feature, even without any concrete numbers, and that is good enough reason to insist an escape hatch that is easy to access by users to exist.

This is especially true for a software with wide userbase, most of which do not run the bleeding edge version. That is how we get users unstuck after releasing our software with a new feature with unforeseen consequences, before we can deliver fixed version in their hands.

Show 5 quoted lines

> This is where I will part this particular debate. If you are not arguing
> for the sake of arguing and if you are genuinely willing to have your
> mind changed then I invite you to reread my blog post, rewatch my
> YouTube video, and reread parts this thread -- watch out for where
> I talk about why LOCAL and REMOTE (and BASE) are useful.

Thanks for your contribution so far.

[Footnote]

*1* They are, however, not obligated to add the feature themselves. They can just honestly say "I did not understand the help offered to make use of it", or "I am too busy, so I am not doing it", or give any other reason or excuse for not doing so. And the rest of us can take it from there by building on top.