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

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

Seth House <seth@eseth.com> writes:

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

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