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