In the following scenario, the destination bookmark moves upon rebase. I would like x=c6d7 after rebasing y=46bc to produce y=1d45. This would be consistent with the track.current option which I have enabled. $ hg init; echo a > foo; hg add foo; hg commit -m +foo $ hg book x; hg book y; echo b >> foo; hg commit -m b $ hg update x; echo c >> foo; hg commit -m c; hg glog 1 files updated, 0 files merged, 0 files removed, 0 files unresolved created new head @ changeset: 2:c6d72fa6916f | tag: tip | tag: x | parent: 0:7d9c08f4e648 | user: Jed Brown <jed@59A2.org> | date: Fri Jul 09 01:05:18 2010 +0200 | summary: c | | o changeset: 1:46bc8d99e1f3 |/ tag: y | user: Jed Brown <jed@59A2.org> | date: Fri Jul 09 01:05:14 2010 +0200 | summary: b | o changeset: 0:7d9c08f4e648 user: Jed Brown <jed@59A2.org> date: Fri Jul 09 01:05:10 2010 +0200 summary: +foo $ hg rebase -s y -d x; sed -i '/^[<=>].*/d' foo; hg resolve -m foo; hg rebase --continue; hg glog merging foo warning: conflicts during merge. merging foo failed! abort: fix unresolved conflicts with hg resolve then run hg rebase -- continue saved backup bundle to /tmp/c/.hg/strip-backup/46bc8d99e1f3-backup.hg @ changeset: 2:1d45d4843b59 | tag: tip | tag: x | tag: y | user: Jed Brown <jed@59A2.org> | date: Fri Jul 09 01:05:14 2010 +0200 | summary: b | o changeset: 1:c6d72fa6916f | user: Jed Brown <jed@59A2.org> | date: Fri Jul 09 01:05:18 2010 +0200 | summary: c | o changeset: 0:7d9c08f4e648 user: Jed Brown <jed@59A2.org> date: Fri Jul 09 01:05:10 2010 +0200 summary: +foo
I see that if I update to y before rebasing y, then x doesn't advance. I think x should not advance in either case since the rebase operation is being applied to y. (I would also find it most natural to be "updated" to y after the rebase.)
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:10 EDT --- This bug was previously known as _bug_ 2277 at http://mercurial.selenic.com/bts/issue2277
I have another repro of what I suspect is the same bug that is pretty clearly wrong. If you rebase a series of commits with a bookmark in the middle. All the bookmarks end up at the tip of the post-rebase series instead of ending up at the corresponding revs. Repro steps, with output: $ hg init bookmark-rebase-demo && cd bookmark-rebase-demo/ /home/dschleimer/data/bookmark-rebase-demo $ hg book init && echo init > init && hg ci -A -m init adding init $ hg book foo && echo foo > foo && hg ci -A -m foo adding foo $ hg up init 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg book bar && echo bar > bar && hg ci -A -m bar adding bar created new head $ hg book baz && echo baz > baz && hg ci -A -m baz adding baz $ hg up bar 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg log -G o changeset: 3:6b2f795c1ff3 | bookmark: baz | tag: tip | user: David Schleimer <dschleimer@fb.com> | date: Mon Jun 04 13:11:45 2012 -0700 | summary: baz | @ changeset: 2:6bd11baa1e2f | bookmark: bar | parent: 0:1f631f0d75f0 | user: David Schleimer <dschleimer@fb.com> | date: Mon Jun 04 13:11:32 2012 -0700 | summary: bar | | o changeset: 1:7e3b92c1dc70 |/ bookmark: foo | user: David Schleimer <dschleimer@fb.com> | date: Mon Jun 04 13:11:04 2012 -0700 | summary: foo | o changeset: 0:1f631f0d75f0 bookmark: init user: David Schleimer <dschleimer@fb.com> date: Mon Jun 04 13:10:56 2012 -0700 summary: init $ hg rebase -d foo saved backup bundle to /data/users/dschleimer/bookmark-rebase-demo/.hg/strip-backup/6bd11baa1e2f-backup.hg $ hg log -G @ changeset: 3:8b51ee0d5ea3 | bookmark: bar | bookmark: baz | tag: tip | user: David Schleimer <dschleimer@fb.com> | date: Mon Jun 04 13:11:45 2012 -0700 | summary: baz | o changeset: 2:3469ef1c345b | user: David Schleimer <dschleimer@fb.com> | date: Mon Jun 04 13:11:32 2012 -0700 | summary: bar | o changeset: 1:7e3b92c1dc70 | bookmark: foo | user: David Schleimer <dschleimer@fb.com> | date: Mon Jun 04 13:11:04 2012 -0700 | summary: foo | o changeset: 0:1f631f0d75f0 bookmark: init user: David Schleimer <dschleimer@fb.com> date: Mon Jun 04 13:10:56 2012 -0700 summary: init It seems pretty clear to me that bar should be at 3469ef1c345b after the rebase rather than tip.
Agree, this is a bug. I've seen this occasionally, but haven't been able to construct steps to reproduce when I actually have time to take a look.
Unless someone else gets to this first, I'll most likely look into fixing it in a couple of weeks. This is likely to be important for our Mercurial workflow.
It's on my list of things to do, but I am not sure if I have time in the next 1-2 months for fixing that.
Fixed in 2.2.3 by: 4116504d1ec4 bookmarks: correctly update current bookmarks on rebase