Consider the following repo: hg init lol cd lol echo a > a hg addr hg ci -m a hg up 0 echo b > b hg addr b hg book b hg ci -m b hg up 0 echo c > c hg addr c hg book c hg ci -m c hg phase -p 'all()' Situation looks like this: hg log -G -T '{bookmarks}' @ c | | o b |/ o Now rebase with --keep: hg rebase -r b%c -d c --keep At hg 4.1, the b bookmark ends on the rebased commit. On 4.2 the bookmark does not move. I bisected the problem to the following commit: https://www.mercurial-scm.org/repo/hg/rev/3b7cb3d17137 There's intentional BC, but it talks about obsolete commits. With --keep there is no obsolescence, so this is extra BC which was not intended. Aside, that's two annoyances now that have bit me when upgrading Mercurial. Please don't forget the lessons of http://stevelosh.com/blog/2012/04/volatile-software/ I don't want to be afraid of upgrading Mercurial.
If you feel strongly about not having behaviors change, then don't use experimental features like obsolete markers. sjl's point is valid and something I think about a lot, but not when it comes to opt-in experimental behaviors.
Here's a patch for stable that demonstrates the regression: # HG changeset patch # User Augie Fackler <augie@google.com> # Date 1505748402 14400 # Mon Sep 18 11:26:42 2017 -0400 # Branch stable # Node ID 0a453f68950c586265dde3141f75a3168db623ff # Parent 1908dc95863957aa1a8375c91bd02d1c7bb3d577 rebase: add test for issue5682, with expected outputs taken from hg 4.2 diff --git a/tests/test-rebase-bookmarks.t b/tests/test-rebase-bookmarks.t --- a/tests/test-rebase-bookmarks.t +++ b/tests/test-rebase-bookmarks.t @@ -210,3 +210,47 @@ as --rev arguments (issue3950) rebasing 6:f677a2907404 "bisect2" rebasing 7:325c16001345 "bisect3" (tip bisect) saved backup bundle to $TESTTMP/a3/.hg/strip-backup/345c90f326a4-b4840586-rebase.hg (glob) + + $ cd .. + +Test that bookmarks end up where we expect (issue5682) + + $ hg init lol + $ cd lol + $ echo a > a + $ hg addr + adding a + $ hg ci -m a + $ hg up 0 + 0 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ echo b > b + $ hg addr b + $ hg book b + $ hg ci -m b + $ hg up 0 + 0 files updated, 0 files merged, 1 files removed, 0 files unresolved + (leaving bookmark b) + $ echo c > c + $ hg addr c + $ hg book c + $ hg ci -m c + created new head + $ hg phase -p 'all()' + $ hg log -G -T '{desc} {bookmarks}' + @ c c + | + | o b b + |/ + o a + + $ hg rebase -r b%c -d c --keep + rebasing 1:d2ae7f538514 "b" (b) + $ hg log -G -T '{desc} {bookmarks}' + o b b + | + @ c c + | + | o b + |/ + o a +
(+some people that know about the rebase refactor)
I think it's desirable to restore the old behavior because "hg rebase -h" says: Rebase will destroy original commits unless you use "--keep". It will also move your bookmarks (even if you do). I'll send a patch.
Bug marked urgent for 10 days, bumping
Will be fixed by https://phab.mercurial-scm.org/D727
Fixed by https://mercurial-scm.org/repo/hg/rev/2f427b57bf90 Jun Wu <quark@fb.com> rebase: move bookmarks with --keep (issue5682) This is a regression caused by 3b7cb3d17137. We have documented the behavior in rebase help: Rebase will destroy original commits unless you use "--keep". It will also move your bookmarks (even if you do). So let's restore the old behavior. It is done by changing `scmutil.cleanupnodes` to accept more information so a node could have different "movement destination" from "successors". It also helps simplifying the callsite as a side effect - the special bookmark movement logic in rebase is removed. Differential Revision: https://phab.mercurial-scm.org/D727 (please test the fix)
Bug was set to TESTING for 14 days, resolving