[PATCH evolve-ext] rebase: refuse to create divergence when using changeset evolution

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sat Nov 21 19:24:03 CST 2015



On 11/20/2015 03:14 PM, Laurent Charignon wrote:
> # HG changeset patch
> # User Laurent Charignon <lcharignon at fb.com>
> # Date 1447957389 28800
> #      Thu Nov 19 10:23:09 2015 -0800
> # Node ID b817cfe239a326017e9345744963c19ef6b8c0e8
> # Parent  8b9c04fb4c7e6d6cb872c63f7289ea679296dd3e
> rebase: refuse to create divergence when using changeset evolution
>
> When a rebase operation is about to create divergence, rebase now aborts.
> If the user wants to create divergence anyway, it can be done using the config
> option: rebase.allowdivergence.

I'm not sure about the option, do we have a rebase section already? Wr 
should probably move forward with an experiemental option. The skipping 
behavior probably need controllability too. We should probably think 
about both at the same time.

> The error message looks like:
>      abort: rebase cannot create divergent changesets
>      (set the config rebase.allowdivergence=True if you want to allow divergence)
>
> In the test output we don't see the warning message about divergence being
> created because evolve is not enabled for the test.
>
> diff --git a/hgext/rebase.py b/hgext/rebase.py
> --- a/hgext/rebase.py
> +++ b/hgext/rebase.py
> @@ -1222,6 +1222,15 @@
>                   # plain prune
>                   obsoletenotrebased[s] = None
>
> +        # Divergence is created if an obsolete commit is rebased on a
> +        # destination with none of its successors
> +        if not repo.ui.configbool('rebase', 'allowdivergence'):
> +            if set(allsuccessors.values()) - set(obsoletenotrebased.keys()):
> +                hint = _('set the config rebase.allowdivergence=True if you'
> +                         ' want to allow divergence')
> +                raise error.Abort(
> +                    _('rebase cannot create divergent changesets'), hint=hint)
> +

I think I see a simpler version of this logic. We already have some code 
that:

1) detect if the changeset is obsolete
2) skip if the successors are in destination (or pruned)

If the changeset is obsolete (1) but not in destination (2), creating a 
successors for it will create divergence. So reusing the conditional for 
the existing skipping code may be better here.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list