Proposal: discourage packagers from enabling merge-tool configs

Mads Kiilerich mads at kiilerich.com
Wed Mar 11 10:29:37 CDT 2015


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.

/Mads


More information about the Mercurial-devel mailing list