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.
When collapsing changesets with rebase, you get a chance to edit the commit
message manually, but there is no way to pass this message from the command
line. This patch adds a `--message` (with short form `-m`) and `--logfile`
(with short form `-m`) options to the rebase command. These options suppresses
the generation of the default commit message, and instead use the message
provided in the option (in case of `-m`) or in the file it points to (in case
of `-l`).
If you use this option without the `--collapse` option, it will raise an
error.
Options documentation edited by Patrick Mezard <pmezard@gmail.com>
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
When a changeset is skipped, rebase keeps the previous target as next
target and if the skipped cset is the first one, the recorded target is
actually the original target.
--abort did not detect this situation but simply stripped away the cset.
Previously, it only checked for an mq patch if the user explicitly
passed -d/--dest. But rebasing onto an mq patch is a bad idea
regardless of how we determine the rebase destination.
They are not needed inside triple-quoted strings and they confuse the
line number computation done in i18n/hggettext. The script tries to
find the docstring in the source file. When \" in the source is turned
into just " in the docstring, the docstring can no longer be found.
- add a paragraph about default dest/source changesets
- option help: say "changeset" not "revision"
- option help: explain -b/--base better
- clarify that -a/--abort and -c/--continue are different from the
other options
This option is useful when other extensions (e.g., pbranch) want to
use rebase --collapse and append other things before committing.
This is not intended to be used from command line.
- add a paragraph about default dest/source changesets
- option help: say "changeset" not "revision"
- option help: explain -b/--base better
- clarify that -a/--abort and -c/--continue are different from the
other options
When rebasing an intermediate revision, rebase keeps a parent relationship
with the original parent. This option forces the removal of this relationship.
In more depth, it 'fakes' null merges between the target revision and the
ancestors of source, dropping every change from the ancestors.
The result is that every change in source and its descendants will be rebased,
ignoring the changes in its ancestors.
Separate rebase-specific functions, in order to provide a better base to
extend rebase's capabilities.
Note that this will be useful especially to share functions with 'adapt'.
(issue1561)
Before this change, newancestor was used only once as a replacement
for ancestor.ancestor, but merge.update calls ancestor.ancestor
several times, so it ends up with the "wrong" ancestor (the real
ancestor, but we want the parent of the rebased changeset for all but
the first rebased changeset).
Added a new test case for this: test-rebase-newancestor.
Also, in one scenario in test-rebase-collapse, there was a spurious
conflict caused by the same issue, so that test case was fixed by
removing the now unneeded conflict resolution and the output was
adapted accordingly.
This only happens when using --base (or no source selection options), as
rebase already aborts in this situation when using --source.
Without this change you get an abort from the underlying merge, and the
repository is in a different state than you started with (the working
dir parent is changed).