The named branch of the leaf changeset can be changed by updating to it,
setting the branch, and amending.
But previously, there was no good way to *just* change the branch of several
linear changes. If rebasing changes with another parent to '.', it would pick
up a pending branch change up. But when rebasing changes that have the same
parent, it would fail with 'nothing to rebase', even when the branch name was
set differently.
To fix this, allow rebasing to same parent when a branch has been set.
This changeset finally make 'hg rebase' choose its default destination using the
same logic as 'hg merge'. The previous default was "tipmost changeset on the
current branch", the new default is "the other head if there is only one". This
change has multiple consequences:
- Multiple tests which were not rebasing anything (rebasing from tipmost head)
are now rebasing on the other "lower" branch. This is the expected new
behavior.
- A test is now explicitly aborting when there is too many heads on the branch.
This is the expected behavior.
- We gained a better detection of the "nothing to rebase" case while performing
'hg pull --rebase' so the message have been updated. Making clearer than an
update was performed and why. This is beneficial side-effect.
- Rebasing from an active bookmark will behave the same as 'hg merge' from a
bookmark.
This warning exists to prevent git users from prematurely polluting
their namespace when trying out Mercurial. But for repos that already
have multiple branches, understanding what branches are is not
optional so we should just shut up.
In plain `hg log` there is no indication that a commit closes a
branch. You can use hg log --debug, but this is too verbose. A simple
idea copied from thg and other graphical viewers is to display the
node for a closing-branch commit as a horizontal line.
I think this technically is a BC if we consider the graphlog to be
part of the stdout API, but I really can't imagine who the hell is
parsing the graphlog to determine information about commits.
Previously, a backup bundle could overwrite an existing bundle and cause user
data loss. For instance, if you have A<-B<-C and strip B, it produces backup
bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it
overwrites the existing B-backup.hg and C is lost.
The fix is to add a hash of all the nodes inside that bundle to the filename.
Fixed up existing tests and added a new test in test-strip.t
Show status messages while rebasing, similar to what graft do:
rebasing 12:2647734878ef "fork" (tip)
This gives more context for the user when resolving conflicts.
Globbing the hash made it harder to maintain tests with run-tests -i when it
was so far by the generated test output.
The hashes are stable and we just need to add a (glob).
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.