[PATCH] merge: when --tool is specified, disable HGMERGE by setting to empty string

[Matt Mackall]

On Tue, 2010-10-19 at 11:13 -0500, Steve Borho wrote:
> On Tue, Oct 19, 2010 at 10:57 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> > On 10/19/2010 06:20 AM, Steve Borho wrote:
> >>
> >> # HG changeset patch
> >> # User Steve Borho<steve at borho.org>
> >> # Date 1287462014 18000
> >> # Node ID 096444ceebdf61e58466ad1c85bbca1019fab76b
> >> # Parent  ef5eaf53f4f73ee1e225f5c524cb51ed1e7bb973
> >> merge: when --tool is specified, disable HGMERGE by setting to empty
> >> string
> >>
> >> HGMERGE has different semantics than ui.merge.  HGMERGE should hold the
> >> name
> >> on an executable in your path, or an absolute tool path.  As such, it's
> >> not
> >> safe to simply copy the user's specified --tool value into HGMERGE.
> >>  Instead,
> >> we disable HGMERGE by setting it to an empty string.
> >
> > Sorry for being a bit late here ...
> >
> > My intuition - which in this case doesn't directly conflict with the help
> > texts - says that this option should guarantee that the specified tool is
> > used to merge all files that are merged, no matter what.
> >
> > But AFAICS it doesn't overrule merge-patterns? I think that one of the use
> > cases for this option is to overrule merge-patterns for individual files.
> >
> > I think it would be better to introduce a new 8th merge tool selection
> > option at the top of filemerge._picktool, rather than overloading ui.merge
> > and trying to patch HGMERGE.
> 
> Hmm, called my bluff.   Ok, how about ui.forcemerge (not documented in
> hgrc(1)) that takes precedence over HGMERGE and bypasses file pattern
> checks?  The merge and resolve commands would need to clear the config
> value at their finish.

I think we've now fully recapitulated the discussion we had on this
issue last time around.

> > Btw: Isn't it a problem to force config settings in ui objects which might
> > have a lifetime that spans several "API" calls? (With reference to
> > http://www.selenic.com/pipermail/mercurial-devel/2010-October/025387.html )
> >
> > Finally: Wouldn't it be convenient if --tool= (without arguments) meant
> > internal:fail ?

No thanks. Our option parser doesn't really like empty strings anyway.

-- 
Mathematics is the supreme nostalgia of our time.