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

[Mads Kiilerich]

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.

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 ?

/Mads