[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