Proposal: discourage packagers from enabling merge-tool configs

[Augie Fackler]

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.

> 
> /Mads

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150311/502abb97/attachment.pgp>