Proposal: discourage packagers from enabling merge-tool configs

Augie Fackler raf at durin42.com
Wed Mar 11 10:33:56 CDT 2015


On Mar 11, 2015, at 11:32 AM, Augie Fackler <raf at durin42.com> 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.

Another thought: maybe we could be more judicious about what tools are enabled out of the box. It strikes me as very likely that gvimdiff users can be bothered to enable something if they need it (ditto for whatever goop you'd use to do merging in emacs.)

>> 
>>> (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.
> 
>> 
>> /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/32d7cd64/attachment.pgp>


More information about the Mercurial-devel mailing list