Bug 2277 - bookmark moves on rebase with track.current
Summary: bookmark moves on rebase with track.current
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: David Schleimer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-09 07:45 UTC by Jed Brown
Modified: 2012-07-29 14:57 UTC (History)
7 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jed Brown 2010-07-09 07:45 UTC
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
Comment 1 Jed Brown 2010-07-09 08:14 UTC
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.)
Comment 2 Bugzilla 2012-05-12 09:10 UTC

--- 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
Comment 3 David Schleimer 2012-06-04 17:21 UTC
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.
Comment 4 Augie Fackler 2012-06-04 19:27 UTC
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.
Comment 5 David Schleimer 2012-06-04 20:02 UTC
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.
Comment 6 David Soria Parra 2012-06-05 04:56 UTC
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.
Comment 7 Matt Mackall 2012-07-29 14:57 UTC
Fixed in 2.2.3 by:

4116504d1ec4 bookmarks: correctly update current bookmarks on rebase