[PATCH V2] rebase: move bookmark to destination for commits becoming empty (issue5627)

Jun Wu quark at fb.com
Mon Jul 24 23:47:00 UTC 2017


Excerpts from Martin von Zweigbergk's message of 2017-07-24 09:29:09 -0700:
> On Fri, Jul 21, 2017 at 9:15 PM, Martin von Zweigbergk
> <martinvonz at google.com> wrote:
> > On Fri, Jul 21, 2017 at 6:18 PM, Jun Wu <quark at fb.com> wrote:
> >> # HG changeset patch
> >> # User Jun Wu <quark at fb.com>
> >> # Date 1500686190 25200
> >> #      Fri Jul 21 18:16:30 2017 -0700
> >> # Branch stable
> >> # Node ID 74b3107a9d9a22a38f09abaa0267d7ddb9165af9
> >> # Parent  20436925e0803a98566c934aa3433fc75b6d2704
> >> # Available At https://bitbucket.org/quark-zju/hg-draft 
> >> #              hg pull https://bitbucket.org/quark-zju/hg-draft  -r 74b3107a9d9a
> >> rebase: move bookmark to destination for commits becoming empty (issue5627)
> >>
> >
> > Queued, thanks!
> 
> I started wondering what should happen with bookmarks that are not on
> pruned commits at the bottom om the stack. Consider the following
> case:
> 
>   o  4 D
>   |
>   | o  3 D BOOK
>   | |
>   | o  2 C
>   | |
>   o |  1 B
>   |/
>   o  0 A
> 
>   $ hg rebase -s 2 -d 4
> 
> 
> The resulting graph will be
> 
>   o  3 C
>   |
>   o  2 D
>   |
>   o  1 B
>   |
>   o  0 A
> 
> but where should the bookmark go? Before your cleanupnodes() commit,
> it went on 3, but after the cleanupnodes() commit and this patch (the
> one I'm replying to), it will go on 2. I think the previous behavior
> was better. How do you want to proceed?

Good case.  I agree the previous behavior is better, but the current
behavior also looks okay to me. I think we can reuse `adjusteddest` in D21
to cleanly solve this (and other corner cases).



More information about the Mercurial-devel mailing list