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