# rebase

Contents

- Description
- Commands
  - Change manipulation

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