[PATCH evolve-ext] evolve: handle merge commit with single obsolete parent (issue4389)

[Pierre-Yves David]

On 12/02/2015 12:25 PM, Andrew Halberstadt wrote:
> On 02/12/15 02:58 PM, Pierre-Yves David wrote:
>> On 11/26/2015 06:41 PM, Andrew Halberstadt wrote:
>>> # HG changeset patch
>>> # User Andrew Halberstadt <ahalberstadt at mozilla.com>
>>> # Date 1448588311 18000
>>> #      Thu Nov 26 20:38:31 2015 -0500
>>> # Node ID 21b5e4b3df092855c554331587fdd7b713b9551e
>>> # Parent  72f50a17780674de8f372803a333d43c77230df5
>>> evolve: handle merge commit with single obsolete parent (issue4389)
>>
>> This is a nice change, but it is done in the wrong layer.
>>
>> The relocate function is not expected to know anything about the higher
>> level evolution process. We should not be adding evolution related logic
>> as this patch do.
>>
>> The code modified here is responsible for finding the proper merge base
>> and bail out in case of merge because of the ambiguity. We should add
>> some "parents/base" argument and compute what it should be in the higher
>> function actually calling relocate.
>
> Makes sense. I only put it there because that's where the error message
> was coming from.

The error message is a small layer violation in itself (pleading guilty)

>>> -            r = merge.graft(repo, orig, orig.p1(), ['local', 'graft'])
>>> +            r = merge.graft(repo, orig, pctx, ['local', 'graft'])
>>> +
>>> +            if pother != nullid:
>>> +                # Add back the original second parent which got
>>> nullified
>>> +                # by merge.graft().
>>> +                repo.dirstate.beginparentchange()
>>> +                repo.setparents(repo['.'].node(), pother)
>>> +                repo.dirstate.write(repo.currenttransaction())
>>> +                repo.dirstate.endparentchange()
>>
>> Could we get hg graft able to grat merge instead (basically the same
>> drill as what is needed of relocate)
>>
>> Many thanks for working on this.
>
> I was originally going to fix this in merge.graft, but that would make
> evolve incompatible with older versions of mercurial. Would I need to
> add some sort of version check somewhere? Or does the fact that evolve
> is experimental mean we don't care.

We do not care to much. We are okay with newer feature being only 
available for newer mercurial. eg: having some try except around the 
callgraph to catch the unknown new parameter would do the trick.
-- 
Pierre-Yves David