Stacked Git logo

Stacked Git



stg-rebase - Move the stack base to another point in history


stg rebase [OPTIONS] [committish]


Pop all patches from the current stack, move the stack base to the given new base and push the patches back.

Merge conflicts may arise when patches are being pushed-back onto the stack. If this occurs, resolve the conflicts and then continue the rebase with the following sequence:

stg add --update
stg refresh
stg goto top-patch

Or to skip the conflicting patch:

stg undo --hard
stg push



Interactively manipulate patches in editor


Do not push back patches after rebasing


Check for patches that may have been merged upstream.

When pushing-back patches, each patch is checked to see if its changes already exist in the new stack base. If a patch’s changes are detected to have been merged, the patch will still exist in the stack, but become empty after the rebase operation.


Instead of using the current time as the committer date, use the author date of the commit as the committer date.


Automatically create a temporary stash before the operation begins, and apply it after the operation completes. This allows a rebase to be performed on a dirty work tree. Note however that the final stash application may result in non-trivial conflicts.


Either "allow" or "disallow" pushing a patch with conflicts.

Using --conflicts=allow (or just --conflicts) allows pushing a patch that may result in unresolved merge conflicts. The patch will be pushed and files with conflicts will be left with conflict markers to be resolved manually; or the operation undone with stg undo --hard. This is the default behavior and also corresponds to the "stgit.push.allow-conflicts" variable being set to "true".

Using --conflicts=disallow disallows pushing any patch that would result in merge conflicts. The operation will stop on the last patch that can be pushed without conflicts. This behavior can be configured by setting "stgit.push.allow-conflicts" to "false".


Part of the StGit suite - see stg(1)