[PATCH 2 of 3] mergetools.hgrc: disable vimdiff as a valid proposal for default mergetools

[Pierre-Yves David]

On Thu, Aug 02, 2012 at 04:02:32PM +0200, Mads Kiilerich wrote:
> On 02/08/12 15:35, Pierre-Yves David wrote:
> >On Thu, Aug 02, 2012 at 03:25:44PM +0200, Mads Kiilerich wrote:
> >>On 02/08/12 14:21, pierre-yves.david at logilab.fr wrote:
> >>># HG changeset patch
> >>># User Pierre-Yves David <pierre-yves.david at logilab.fr>
> >>># Date 1343908321 -7200
> >>># Branch stable
> >>># Node ID 68604f26c8b5962dd6bfc3099f6fa3e428fbc91d
> >>># Parent  192441ab174c489bd7bbc61d8bd0e4658f79aeaf
> >>>mergetools.hgrc: disable vimdiff as a valid proposal for default mergetools.
> >>>
> >>>Vimdiff is currently prefered to the default merge tool is no graphical tool are
> >>>available. Use is a very bad idea for multiple reasons:
> >>>
> >>>- People which don't know vim will have an hard time to even understand what
> >>>   happen.
> >>>
> >>>- Most vimer don't use vimdiff themself.
> >>>
> >>>We keep the entry here to ease the use of vimdiff as a mergetool. We just don't
> >>>want it enabled by default.
> >>This will still leave vimdiff enabled and with higher priority than
> >>the internal:merge default.
> >The same files have a merge entry with -100 priority.
> 
> 'merge' from GNU RCS? Not something that is installed on all
> machines ... and probably also one of the tools where having it
> installed wasn't a deliberate choice and doesn't mean that the user
> wants to use it.

It's the closest to the current Mercurial default. I do not find that bad.

> >We would add a -500 priority for internal merge.
> 
> internal:merge is a last resort. It is not in any way recommended or
> best practice. Some users might have gotten used to that mode of
> operation from CVS and prefer that. They are welcome. We should
> however not expose new and innocent users to that - just like we
> should avoid 'merge' and 'vimdiff'.

Well,

1) Vimdiff or other non obvious tools should not be the default,
2) People need a simple way to resolve merge conflict,
3) Solution that allows the user to use its usual text editor are the only viable default solution I see.

This leave use with two approach:

A) generates a single file with <<< === >>> marker in it
B) generates three file babar.py.base babar.py.local babar.py.other

With the A+B solution that generates 4 files on wth marker and the 3 others.

> >
> >>How about introducing internal:abort and something like this in
> >>mergetools.hgrc:
> >>
> >>internal:abort.priority = -1
> >>internal:abort.message =
> >>   No suitable merge tool has been found.
> >>   Please make sure a merge tool of your choice is installed and
> >>configured in Mercurial with a positive priority.
> >>   See 'hg help merge-tools' and 'hg showconfig --debug merge-tools'.

Hinting the user about possible configuration seems a good idea.

Forcing the user to make another mandatory configuration to use Mercurial seems a bad idea.

> >Will this tool create <<< === >>> marker anyway ? They are a pretty ok and standard way to handle merge.
> 
> No, the idea was that internal:abort should abort with the specified
> message.
> 
> And as mentioned above: There are different opinions on whether <<<
> === >>> markers are pretty ok. Not having the ancestor revision
> makes it harder than necessary to resolve correctly.

I agree that the current internalmerge marker are suboptimal. But It does not seems hard to improve it.
I use a version that create:

    <<< local

    This
    is
    the
    local
    version

    ==== base

    This
    is
    the
    common
    ancestor
    version

    ==== other


    This
    is
    the
    merge target
    version

    >>>

And Someone proposed a patch to add the changeset hash to markers. I would find
that awesome. Maybe the branch//bookmark name or description would help too.


So I would propose a default merge tools that:

    1) Warn about the merge-tools help topic
    2) also create nice a useful marker
    3) also create base, other and local files

- A marker only version would be accessible using "internal:mergemarkers"
- A file only version would be would be accessible using "internal:mergefiles"

What d you think about it ?

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120821/b6e8090f/attachment.pgp>