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.
