bzr rebase: weird usage of revision spec
maxb at f2s.com
Tue Nov 24 00:10:46 GMT 2009
Alexander Belchenko wrote:
> 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.
Oops, sorry, you're right. rebase is making an assumption that if your
branch is not diverged from the other branch, there's no point in
rebasing. It's probably an accurate assumption in most cases, but "No
revisions to rebase." is a nonsense error for this situation.
>>> 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.
What I mean is, that given this example dataset, the option "--onto 2"
is merely restating the default - the tip of the target branch is
revision 2, so that would be the default 'onto' revision.
>>> 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.
The reason that it is omitting the last revision is the same bug I
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20091124/5992efaf/attachment.pgp
More information about the bazaar