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

[Steve Borho]

On Tue, Oct 19, 2010 at 1:21 PM, Matt Mackall <mpm at selenic.com> wrote:
> 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.

I don't recall an earlier discussion on this topic.  Is a
ui.forcemerge argument ok, or should I bite the bullet and pass the
override down through merge.py?

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



-- 
Steve Borho