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).
It is not very helpful to have 'Added tag %s for changeset %s' and
similar messages translated into different languages when people work
together using different locales.
We now use English strings without support for translations. If
needed, the user can still supply a custom string for most commands.