bzr rebase: weird usage of revision spec

[Max Bowsher]

Alexander Belchenko wrote:
> 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.

Well, yeah, you have no revisions in b which are not in a.

> 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

A single revision is treated as a stop revision. But...

Bug A: So it seems that rebase, apparently deliberately, replaces
whatever stop revision you give it with its left-parent before actually
doing anything with it. !??!

Bug B, found whilst investigating: If it decides to pull, it does it
even if you used --dry-run!

> bzr rebase --onto 2  # nope

That's a no-op, given the head of branch a is revision 2 anyway.

> bzr rebase -r2..-1  # almost, but it omit your last revision (4b) and again destroy your history

Bug A again.

> (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?

Works around bug A by not exercising the weird codepath.

> 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).

Total WTF for me too. I'd call it an 'obvious' fix, but I get worried
when the way to fix a bug is just to delete some code - it makes me
think I didn't understand the author's intent.

Max.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20091123/25b3116d/attachment.pgp