[PATCH 1 of 7] histedit: simplify computation of `newchildren` during --continue

[Pierre-Yves David]

On 1 oct. 2012, at 23:43, Augie Fackler wrote:

> On Mon, Oct 1, 2012 at 4:37 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>> 
>> On 1 oct. 2012, at 20:19, Augie Fackler wrote:
>> 
>>> On Sep 27, 2012, at 6:07 PM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>>> 
>>>> +    # is there any new commit between the expected parent and "."
>>>> +    # XXX does not take non linear new change in account (but previous
>>>> +    # XXX implementation didn't used them anyway
>>> 
>>> Perhaps we should abort here if that happens? Does that seem reasonable?
>> 
>> I'm not sure it's reasonable to Abort. It could be a valid usage from people who want to extract an independent changes in another branches. There is no related bug in the bug tracker so user does not run over it on their own.
> 
> If we don't handle the case, why don't we abort then with "unsupported
> use case, file a bug" or something? My point is mostly that if we're
> going to have these XXX comments, I'd rather have something more
> defensive now that we've noticed the potential defect.

The current handling for the case is to leave the extra commit in place as if there have always been there. It does not do peculiar arms in most case (it's even probably what the user want). In a few rare other (when you do that during fold) it will either strip the extra changeset or make them unstable (if you use evolution).

Moreover, is currently not trivial to catch (but not that hard either) so my willingness to delay the handling of this "issue".

-- 
Pierre-Yves