Contents
command to move sets of revisions to a different ancestor
This extension lets you rebase changesets in an existing Mercurial repository.
For more information: https://mercurial-scm.org/wiki/RebaseExtension
move changeset (and descendants) to a different branch:
hg rebase [[-s REV]... | [-b REV]... | [-r REV]...] [-d REV] [OPTION]...
Rebase uses repeated merging to graft changesets from one part of history (the source) onto another (the destination). This can be useful for linearizing local changes relative to a master development tree.
Published commits cannot be rebased (see hg help phases). To copy commits, see hg help graft.
If you don't specify a destination changeset (-d/--dest), rebase will use the same logic as hg merge to pick a destination. if the current branch contains exactly one other head, the other head is merged with by default. Otherwise, an explicit revision with which to merge with must be provided. (destination changeset is not modified by rebasing, but new changesets are added as its descendants.)
Here are the ways to select changesets:
- Explicitly select them using --rev.
- Use --source to select a root changeset and include all of its descendants.
- Use --base to select a changeset; rebase will find ancestors and their descendants which are not also ancestors of the destination.
- If you do not specify any of --rev, --source, or --base, rebase will use --base . as above.
If --source or --rev is used, special names SRC and ALLSRC can be used in --dest. Destination would be calculated per source revision with SRC substituted by that single source revision and ALLSRC substituted by all source revisions.
Rebase will destroy original changesets unless you use --keep. It will also move your bookmarks (even if you do).
Some changesets may be dropped if they do not contribute changes (e.g. merges from the destination branch).
Unlike merge, rebase will do nothing if you are at the branch tip of a named branch with two heads. You will need to explicitly specify source and/or destination.
If you need to use a tool to automate merge/conflict decisions, you can specify one with --tool, see hg help merge-tools. As a caveat: the tool will not be used to mediate when a file was deleted, there is no hook presently available for this.
If a rebase is interrupted to manually resolve a conflict, it can be continued with --continue/-c, aborted with --abort/-a, or stopped with --stop.
Examples:
move "local changes" (current commit back to branching point) to the current branch tip after a pull:
hg rebase
move a single changeset to the stable branch:
hg rebase -r 5f493448 -d stable
splice a commit and all its descendants onto another part of history:
hg rebase --source c0c3 --dest 4cf9
rebase everything on a branch marked by a bookmark onto the default branch:
hg rebase --base myfeature --dest default
collapse a sequence of changes into a single commit:
hg rebase --collapse -r 1520:1525 -d .
move a named branch while preserving its name:
hg rebase -r "branch(featureX)" -d 1.3 --keepbranches
stabilize orphaned changesets so history looks linear:
hg rebase -r 'orphan()-obsolete()' -d 'first(max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete())::) + max(::((roots(ALLSRC) & ::SRC)^)-obsolete()))'
Configuration Options:
You can make rebase require a destination if you set the following config option:
[commands] rebase.requiredest = True
By default, rebase will close the transaction after each commit. For performance purposes, you can configure rebase to use a single transaction across the entire rebase. WARNING: This setting introduces a significant risk of losing the work you've done in a rebase if the rebase aborts unexpectedly:
[rebase] singletransaction = True
By default, rebase writes to the working copy, but you can configure it to run in-memory for better performance. When the rebase is not moving the parent(s) of the working copy (AKA the "currently checked out changesets"), this may also allow it to run even if the working copy is dirty:
[rebase] experimental.inmemory = True
Return Values:
Returns 0 on success, 1 if nothing to rebase or there are unresolved conflicts.
Options:
-s, --source <REV[+]> | |
rebase the specified changesets and their descendants | |
-b, --base <REV[+]> | |
rebase everything from branching point of specified changeset | |
-r, --rev <REV[+]> | |
rebase these revisions | |
-d, --dest <REV> | |
rebase onto the specified changeset | |
--collapse | collapse the rebased changesets |
-m, --message <TEXT> | |
use text as collapse commit message | |
-e, --edit | invoke editor on commit messages |
-l, --logfile <FILE> | |
read collapse commit message from file | |
-k, --keep | keep original changesets |
--keepbranches | keep original branch names |
-D, --detach | (DEPRECATED) |
-i, --interactive | |
(DEPRECATED) | |
-t, --tool <VALUE> | |
specify merge tool | |
--stop | stop interrupted rebase |
-c, --continue | continue an interrupted rebase |
-a, --abort | abort an interrupted rebase |
--auto-orphans <VALUE> | |
automatically rebase orphan revisions in the specified revset (EXPERIMENTAL) | |
-n, --dry-run | do not perform actions, just print output |
-T, --template <TEMPLATE> | |
display with template | |
--confirm | ask before applying actions |
[+] marked option can be specified multiple times