Stacked Diffs Enterprise
An opt-in extension of PR mode for teams that split large changes into a chain of small, dependent pull requests instead of one big one — the workflow Graphite and Sapling popularize. Codeveira links the stack automatically as PRs open, and rebases it forward automatically as each layer merges.
Overview
Without stacked diffs, a chain of dependent PRs is a manual chore: you target PR 2 at PR 1's branch, and once PR 1 merges you have to retarget PR 2 at the real base branch and rebase it yourself — by hand, for every layer, every time something below it lands. With multiple contributors stacking on each other's work, this quickly turns into the main source of friction in the workflow.
Stacked diffs removes that manual step. Codeveira detects the stack relationship the moment a PR is opened, and when a parent PR merges — from Codeveira's own Merge button or directly on the platform — every open descendant is rebased onto the new base and cascaded down automatically, with no action required from anyone in the stack.
How it works
- Open a PR targeting another still-open PR's own source branch instead of your usual base branch (e.g.
main), and Codeveira links it as that PR's stacked child automatically — no separate "start a stack" step. - The review page shows the full stack, from root to every leaf, so anyone reviewing a middle or bottom layer can see the whole chain and where their PR sits in it.
- A PR can have more than one child — the stack doesn't have to be a straight line. Two people can each build their own follow-up PR on top of the same parent.
- A PR's place in the stack is a historical record: once linked, it stays linked even after the parent merges — only the "is this still blocked?" state changes.
Enabling stacked diffs
Make sure PR mode is already enabled on the repository — stacked diffs only applies to PR-mode reviews.
On the repository's Edit page, tick Enable stacked diffs. It's off by default and requires an Enterprise license.
Nothing else to configure — no new webhook events beyond what PR mode already needs. Just open your next PR against the branch of the PR it builds on.
How the auto-rebase works
When a PR with open children merges, Codeveira computes the new base and rebases every child onto it:
- A direct child is rebased onto the merged PR's new head, and its own target branch is updated to whatever the merged PR was targeting — so it's now correctly aimed at the real base branch instead of the PR that just landed.
- A grandchild (a PR stacked on the child) is rebased onto the child's own freshly-rebased head, not the original merge point — the cascade always uses each layer's just-updated state as the next layer's base. Its target branch doesn't change, since it's still correctly aimed at its own parent's branch.
- Each PR in the stack is rebased independently. If one PR's rebase hits a conflict, its siblings and their own descendants still proceed normally — one blocked branch never stalls the rest of the stack.
The rebase itself is applied via each platform's own API — Codeveira never shells out to git against a local clone. A rebase that can be applied cleanly completes with no visible interruption; reviewers and watchers are notified either way.
Conflicts & manual retry
A rebase can't always be applied automatically — if the newly-merged code and the child PR both changed the same lines of the same file, that's a real conflict Codeveira won't guess how to resolve. When that happens:
- The affected PR is flagged needs manual rebase, with the conflicting file named in the message.
- Its reviewers, watchers, and author are notified, the same as any other review event.
- Nothing is written to the branch — a detected conflict stops the rebase before any change is pushed, so the PR's existing state is untouched and safe.
Once the conflict is resolved outside Codeveira — typically by pushing a merge or rebase commit to the PR's branch yourself, or amending the PR — a Retry rebase button on the review page (visible to the PR's author or an admin) re-attempts just that one PR. On success, it cascades into that PR's own children exactly like the automatic path would have.
The merge gate
A PR that's still stacked on a parent which hasn't merged yet cannot be merged from Codeveira — the Merge button is replaced with an explanation of which parent it's waiting on. This mirrors the same "can't accidentally jump the queue" reasoning as Codeveira's other optional merge gates (risk scoring, task tracker status, CI/SAST).
A global admin can override the gate and merge out of order if there's a genuine reason to (e.g. the parent PR is being abandoned and the child no longer depends on it in practice). Overriding does not retroactively unlink the stack relationship.
Troubleshooting
The "Enable stacked diffs" checkbox doesn't appear
Three possible causes: PR mode isn't enabled on the repository yet (enable that first), the current license is below Enterprise (check Settings → License), or the repository's source platform is Gerrit, which doesn't support stacking.
A PR didn't get linked as a stacked child
The link only happens if the PR's target branch exactly matches another PR's source branch, and that other PR is still open at the moment this one opens — a closed or already-merged PR's branch is never picked as a parent. If you opened the child PR before double-checking the target branch, closing and reopening it against the correct branch will re-run detection.
A merged parent's children didn't rebase
Check whether any of them are flagged needs manual rebase on their review page — that means a real conflict was hit and is waiting on a manual retry, not a bug. If none are flagged and nothing happened at all, confirm stacked diffs is still enabled on the repository (it's checked again at rebase time, not just when the stack was first linked).
Retry rebase button is missing
It only appears on a PR currently flagged needs manual rebase, and only to that PR's author or an admin.
Stacked diffs builds directly on PR mode — set that up first if you haven't.