Proposal: discourage packagers from enabling merge-tool configs

[Mads Kiilerich]

On 03/11/2015 04:38 PM, Augie Fackler wrote:
> On Mar 11, 2015, at 11:36 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>
>> On 03/11/2015 04:32 PM, Augie Fackler wrote:
>>> On Mar 11, 2015, at 11:29 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>>>
>>>> On 03/11/2015 04:12 PM, Augie Fackler wrote:
>>>>>  From IRC just now:
>>>>>> 11:07 < newdan> durin42, well yesterday I had some help figuring out how to
>>>>>>                  make rebase work more like git when conflicts happen (by
>>>>>>                  default on my box it opens up gvimdiff which I don't know, and
>>>>>>                  :qall-ing out made me actually lose some of my work)
>>>>> This has burned me too. I believe our current position is that we think packagers should enable all the merge tools. I think that's dangerous for the above reason. Can we change that to recommend including it as a documentation sample, but to not enable them by default?
>>>> It has burned my users more that the merge tool they install doesn't work out of the box.
>>>>
>>>>> (It strikes me as particularly likely that gvimdiff is installed on machines without users explicitly requesting it, and that it'll be hard for non-advanced-vim types to get out of it without leaving the merge in a completely resolved state, which is annoying at best and catastrophic for a newbie at worst.)
>>>> I agree that it would make sense to have a tool with higher precence than gvimdiff. That would be less of a break of backwards compatibility.
>>>>
>>>> That higher precedence tool could perhaps just be failing with a "please configure your merge tool" error. It could also fall back to internal merge, but I think there is too high risk that new users will end up using plain conflict markers and get a very bad user experience and blame Mercurial.
>>> Please carefully consider what I'm talking about: users (including *me*) are getting trapped in a merge tool they don't understand, and then are *unable* to even get something as basic as conflict markers. I agree that conflict markers are a terrible user experience, but frankly, they ALWAYS work, whereas if you stick me in gvimdiff I have to go on an hgrc-whack-a-mole expedition to find where the offending merge tool is.
>>>
>>> I'm sympathetic to the notion that we want merge tools to be easy to use, but I really very strongly feel that the current default is extremely dangerous for newbies.
>> Yes, I said I agreed that we shouldn't fall back to gvimdiff but have some other option with higher precedence. Where do we disagree?
> If gvimdiff is the only merge-tool on my system, I still never ever want to see it, and I suspect this is true of the vast majority of people that don't understand how to use gvimdiff. If I understand your position, you want merge-tools enabled by default, whereas I want them *all* off by default, but with easy examples of how to enable the sensible ones. I'm happy to compromise somewhere if we can come up with a list of merge tools that aren't abstruse to escape if you end up in them unintentionally.

Why do you not want the good and "probably intentionally installed" 
merge tools to be detected automatically?

/Mads