rebase

Contents

command to move sets of revisions to a different ancestor

Description

This extension lets you rebase changesets in an existing Mercurial repository.

For more information: https://mercurial-scm.org/wiki/RebaseExtension

Commands

Change manipulation

rebase

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:

  1. Explicitly select them using --rev.
  2. Use --source to select a root changeset and include all of its descendants.
  3. Use --base to select a changeset; rebase will find ancestors and their descendants which are not also ancestors of the destination.
  4. 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