[PATCH 2 of 2] scmutil: add a cleanupnodes method for developers

Martin von Zweigbergk martinvonz at google.com
Wed Jun 28 14:22:00 EDT 2017

On Wed, Jun 28, 2017 at 11:08 AM, Jun Wu <quark at fb.com> wrote:
> Excerpts from Martin von Zweigbergk's message of 2017-06-28 10:18:22 -0700:
>> If we're pruning a merge, this puts the bookmark on an "arbitrary"
>> parent. I see that that's how it already works and I suppose you just
>> preserved that behavior. Should we simply do the same for the
>> divergence case above?  The ProgrammingError is a little unfortunate,
>> because the only way to prevent it is by not calling this method, AFAICT
>> (sure, you can handle that specific bookmark outside, but then you're not
>> saving that much). So maybe just use max() for the divergence too?
> The current ProgrammingError only happens when split a commit to something
> with multiple roots. Like split A to B and C, and ancestor(B+C) is not in
> [B, C]. I think that's a wrong split implementation and therefore raised
> ProgrammingError.  Normally you won't be able to get into that situation.

For the regular "hg split", I agree that's wrong. But one could
imagine a "hg splitindependent" that takes a commit and splits it up
into two that can be sent for review independently.

> If we don't care about that corner case, I think "max()" makes sense to
> simplify the code and user experience.

I think that makes sense. I like the symmetry that gives with pruning of merges.

One could of course consider adding a flag "hg strip
--move-bookmark-to-parent={1,2}" (and similar for my hypothetical
command above) or asking interactively (probably better), but that
also seems awkward. I'd say we can continue to leave the bookmark on
an arbitrary node until someone complains about it.

More information about the Mercurial-devel mailing list