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

[Steve Borho]

On Tue, 2008-01-08 at 15:44 +0100, Arve Knudsen wrote:
> 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. 

If a user is going through the trouble of defining their own tool, it is
most likely going to be assigned to 'default' or to a file filter, both
of which completely override the tool search.  So I don't think this is
necessary.

>         > 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' :)

That works for me.

> > > +  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. 

Sounds like the best solution is to simply fix their descriptions.

-- 
Steve Borho (steve at borho.org)
http://www.borho.org/~steve/steve.asc
Key fingerprint = 2D08 E7CF B624 624C DE1F  E2E4 B0C2 5292 F2C6 2C8C