Prior to this changeset, rebase always left the working directory as a parent of
the last rebased changeset. The is dubious when, before the rebase, the working
directory was not a parent of the tip most rebased changeset.
With this changeset, we move the working directory back to its original parent.
If the original parent was rebased, we use it's successors.
This is a step toward solving issue3813 (rebase loses active bookmark if it's
not on a head)
As of 1ffaca626da1 (first released as part of Mercurial 2.0), the rebase command
accepted ONLY revsets for the source and base arguments and no longer accepted
old-style revision specifications. As a result, some revision names were no
longer recognised, e.g.
hg rebase --base br-anch
abort: unknown revision 'br'!
These arguments are now interpreted first as old-style revision specifications,
then as revsets when no matching revision is found. This restores backwards
compatibility with releases prior to 2.0.
Add two changesets to the scenario so that the bundle can be reused
within three tests.
Before:
@ 5: 'F'
|
| o 4: 'E'
|/|
o | 3: 'D
| |
| o 2: 'C'
|/
| o 1: 'B'
|/
o 0: 'A'
After:
@ 7: 'H'
|
| o 6: 'G'
|/|
o | 5: 'F'
| |
| o 4: 'E'
|/
| o 3: 'D'
| |
| o 2: 'C'
| |
| o 1: 'B'
|/
o 0: 'A'
Revisions 0-1 keep the same number/label. Others were translated by
an offset of 2 (2.C -> 4.E)
So far we've been denying rebasing descendants onto ancestors, but there are
situations in which this kind of operation makes perfect sense to me.
Let's say we have made a commit (or more), that belongs to branch 'dev', on
top of the named branch 'stable':
... a (stable) - b (dev)
but then we realize that b should belong to branch 'stable'.
In these cases a rebase means: "move these csets from named branch A to named
branch B" and there isn't a valid reason to deny it.
This patch basically doesn't block it, if source and destination are
on different named branches.
The old behaviour still applies for rebases across the same named branch.
Can you think of any tricky corner cases in which this new behaviour could
lead to problems? (I bet there are tons of them...)
By the way, I created a brand new .t because I feel there should be more
tests I can't think of at the moment.