[PATCH 3 of 4] hgmerge: remove obsoleted code, update docs

Arve Knudsen arve.knudsen at gmail.com
Tue Jan 8 08:44:05 CST 2008


On Jan 8, 2008 5:19 AM, Steve Borho <steve at borho.org> wrote:

>
> On Mon, 2008-01-07 at 18:10 -0600, Oliver Xymoron wrote:
> > On Mon, 2008-01-07 at 15:20 -0600, Steve Borho wrote:
> > mymerge = supermerge -vkm $local $other $base -o $output
>
> the priority and win path settings are going to be pretty rarely used
> for user-defined tools. In this example they could have just used:
>
> myHtmlPlugin.arguments = -m $local $other $base $output
>

A possibility would be to always assign user-defined tools a certain
priority (configurable via [merge]?), so for instance when one defines a new
tool it is automatically preferred to standard ones.

> So this might want to be [merge-tools] or [merge-helpers] or maybe we
> > even want to combine it with the existing [merge] section too. Then
> > someone can just write:
> >
> > [merge]
> > default = mymerge
> > mymerge = supermerge -vkm $local $other $base -o $output
>
> We could get it down this far pretty easily:
>
> [merge]
> default = supermerge
> supermerge.arguments = -vkm $local $other $base -o $output
>

To minimize required effort even further, we could always rename 'arguments'
to just 'args' :)


> > +  stdout;;
> > +    Should the tool's standard output be used as the merge result.
> > +    Default: False
> > +  check_conflicts;;
> > +    Check whether there are conflicts even though the tool reported
> > +    none. Default: False
> > +  win.regpath_installdir;;
> > +    Specify a pathname in the Windows registry defining the tool's
installation
> > +    directory. The format of this option is like this: <key
name>\<value name>.
> > +    If the (default) key itself actually holds the value, end the
pathname with
> > +    a backslash, so it's clear there is no value name component.
> > +  win.regpath_installpath;;
> > +    Like the former, except that the registry value is taken to specify
the
> > +    installation path of the tool's executable.
>

> > These last two are really confusing.
>
> I'm tempted to only support these fields in the stock tool definitions
> and not expose them to the user.  It's simpler for them to just provide
> the full path to the app (provided it isn't already in $PATH).
>

I don't know about that. Those parameters, while not super-understandable,
are there for a reason. If one doesn't need them when writing a plug-in
definition, ignore them. Maybe they should be in an "advanced settings"
subsection in the documentation, to indicate most people can ignore them.

Arve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20080108/3e93cdbd/attachment.htm 


More information about the Mercurial-devel mailing list