bzr rebase: weird usage of revision spec
Alexander Belchenko
bialix at ukr.net
Thu Nov 19 00:22:20 GMT 2009
I'd like to share my old observation of weirdness in bzr rebase plugin/command. Just recently I've
answered question from bzr-day reader about it: how to force rebase to work?
Here is simple reproduction case:
bzr init a --append-revisions-only # this can be svn trunk actually
cd a
bzr mkdir foo
bzr ci -m1a
cd ..
bzr branch a b
cd b
bzr mkdir bar
bzr ci -m2b
cd ../a
bzr mkdir spam
bzr ci -m2a
cd ../b
bzr merge ../a
bzr ci -m3b
bzr mv foo fu
bzr ci -m4b
bzr rebase
At this point rebase refuses to work and said:
C:\Temp\6\b>bzr rebase
Rebasing on file:///C:/Temp/6/a/
No revisions to rebase.
And now it's almost impossible to figure out how to force this damn thing to rebase. You may start
playing with different options of rebase command: -r, --onto -- but nothing help. You may try to guess:
bzr rebase -r2 # nope, it doing pull instead and destroys your history
bzr rebase --onto 2 # nope
bzr rebase -r2..-1 # almost, but it omit your last revision (4b) and again destroy your history
(in the cases 1 and 3 above after destroying original branch b history I have forced to use bzr
heads --dead & bzr pull --over . -r revid:dead-id)
OK, I'll show you the right answer:
bzr rebase -r2..
That's it. You have to use open range and specify only first revision. What?
I'm rarely use rebase itself, most often I'm run bzr replay, which is way too more do what I mean.
I feel I don't understand something obvious. But maybe I should not.
But this is obvious WTF for me (and not only for me).
More information about the bazaar
mailing list