Updating Stacks

After pushing a stack, you’ll need to make changes: responding to review feedback, adding commits, rearranging order, or squashing. This page covers every common scenario.

In all cases, the workflow is the same: edit your stack locally, then run mergify stack push to sync with GitHub. Stacks ships dedicated commands for every common history rewrite, so you don’t have to drive git rebase -i by hand.

Each editing command accepts a commit as either a short SHA or a Change-Id prefix. Most of them also support --dry-run (-n) to print the plan without touching your branch.

Make your changes, then amend:

git add src/api/users.py
git commit --amend

The Change-Id is preserved automatically. Then push:

mergify stack push

Only the PR corresponding to the amended commit is updated.

To modify a commit that isn’t at the top of your branch, point mergify stack edit at it. Pass a short SHA or Change-Id prefix and the rebase pauses on that commit:

mergify stack edit a1b2c3d

Git stops at the target so you can make changes:

# Make your changes
git add src/models/user.py
git commit --amend
git rebase --continue

Then push:

mergify stack push

Only the amended commit’s PR (and any later PRs whose content shifts) is updated.

To change a commit’s message without touching its contents:

mergify stack reword d4e5f6a -m "feat: add user registration API endpoint"

The Change-Id is preserved, so the PR keeps its identity. Because Stacks derives the PR title and body from the commit message, the corresponding PR’s title and body update on the next push.

List every commit in the order you want, by SHA or Change-Id prefix:

mergify stack reorder d4e5f6a a1b2c3d g7h8i9b

To move a single commit without listing the whole stack, use move with first, last, before, or after:

mergify stack move g7h8i9b first
mergify stack move a1b2c3d after d4e5f6a

The PRs re-chain automatically when you push.

Just commit normally anywhere in your branch:

git add src/api/auth.py
git commit -m "feat: add authentication middleware"

On the next mergify stack push, a new PR is created and inserted at the correct position in the chain.

Drop one or more commits by SHA or Change-Id prefix:

mergify stack drop d4e5f6a

On push, the orphan remote branch is deleted and the remaining PRs re-chain.

To fold a commit into its parent and drop its message, use fixup:

mergify stack fixup g7h8i9b

To combine commits into a target while keeping the target’s message, use squash. Sources go before the into token, the target after it:

mergify stack squash d4e5f6a into a1b2c3d

Pass -m to rewrite the resulting message instead of keeping the target’s:

mergify stack squash d4e5f6a into a1b2c3d -m "feat: add user model and endpoint"

The surviving commit keeps its Change-Id, so the corresponding PR is updated. The absorbed commit’s remote branch is cleaned up automatically.

The history-rewriting commands (reword, reorder, move, drop, fixup, squash) accept --dry-run (-n) to print the resulting plan without changing your branch:

mergify stack reorder d4e5f6a a1b2c3d g7h8i9b --dry-run

When you amend a commit that already has a PR, reviewers see a new revision but not the reason behind it. Attach a note before pushing to explain the change:

git commit --amend
mergify stack note -m "address review: rename foo() to bar()"
mergify stack push

The note travels with the stack and appears in the PR’s revision history, so reviewers understand what changed between revisions without diffing SHAs. See Reviewing Stacks for the reviewer’s view.

By default, mergify stack push keeps a revision-history comment on each PR up to date. Pass --no-revision-history (or set mergify-cli.stack-revision-history to false) to turn it off.

When the bottom PR in your stack merges into main, bring your local branch back in sync:

mergify stack sync

sync fetches the latest main, detects which commits already merged, drops them from your branch, and rebases the rest. Then push to update the remaining PRs:

mergify stack push

Before the merge, your stack looks like this:

After PR #1 merges, commit A lands on main. The remaining PRs re-chain:

sync rebases on main, detects that the merged commit is already there, and skips it. The remaining PRs update as needed on the next push.