I'm using a workflow based on rebasing my subtree onto a continually growing trunk. I'm using bookmarks with track.current = True b | | | y | / z | / / | x---- | / |/ a | Suppose each commit in the above tree is bookmarked by its name. I do the following: hg up b hg rebase --detatch -s x -d b Expected Results: y / z / / x---- / / b | | | a Actual Results: xyz / b / / o---- / / o | | | a Does this have anything to do with my use of track.current = True?
Also - running mercurial 1.5.2 on OSX 10.5 via macports.
I just wrote an extension to fix this issue: http://hg.mozilla.org/users/bobbyholley_stanford.edu/hgext/file/tip/peacepipe.py I'd like to publish it in a blog post in a day or two. Before I do that, can somebody take a look at it? I've never written anything in python before (and certainly nothing for mercurial), so I'm sure there are plenty of things that could be improved. I'm also not sure how well it'll play with rebases interrupted by merges. I haven't tested that yet.
Can you give me a script to reproduce? It seems that the bookmarks are not lost but rather the bookmark is not tracked correctly.
Shrug - I think the steps to reproduce given below should be enough. hg rebase --detach deletes commits and adds new ones in their place, and there's no handling in either extension for making sure that bookmarks get mapped over. That's what peacepipe fixes. You should also coordinate with the rebase maintainer, as I think he might have plans for incorporating a fix as well.
hgbot missed this one... I'm just posting the same message here. Fixed by http://selenic.com/repo/hg/rev/c0ccd70df52c Stefano Tortarolo <stefano.tortarolo@gmail.com> rebase: reset bookmarks (issue2265 and issue2873) (please test the fix)
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:10 EDT --- This bug was previously known as _bug_ 2265 at http://mercurial.selenic.com/bts/issue2265