bzr rebase: weird usage of revision spec

[Alexander Belchenko]

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.

Hmm? I'm sorry? Your comments forced me to understand that I totally 
don't understand how rebase supposed to work.

In my understanding rebase should rebase history of current branch on 
the top of upstream branch. Is it correct? No? What is correct 
definition then?

If my definition correct then rebase supposed to rewrite my history on 
top of 2a revision from branch a. And BTW if I don't do merge from a 
before rebase (after committing 2b revision) then simply `bzr rebase` 
works auto-magically.

In any case current behavior is weird.

> 
>> 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!

Ouch! I'd say this is very serious bug (or flaw) in rebase plugin.

>> bzr rebase --onto 2  # nope
> 
> That's a no-op, given the head of branch a is revision 2 anyway.

I don't understand this.

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

Hm? I don't understand this either.

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

/me too.