Stacked PRs

Stacked PRs is the workflow where you write PR 1, submit it, write PR 2 on top of PR 1's branch, submit PR 2, write PR 3 on top of that, and so on — without waiting for any of them to land. CPU pipelining applied to code review. The motivation is throughput across timezone latency: if review takes 12 hours and you'd otherwise be blocked, stacking is how you stay productive.

Why it works

• The reviewer reads PRs one at a time anyway.
• Each PR is small and focused (which it has to be — stacking makes sloppy PRs even worse).
• A landed PR rebases the rest of the stack forward; jj does this in one operation, git tools simulate it via external metadata.

Why git makes it hard

Git has no notion of successor commits and no notion of a stack as a first-class object. Tools like Graphite work around this by maintaining a separate branch-metadata store outside git, which can drift out of sync the moment you touch git directly. See billjings-git-not-fine for the full version of this argument.

Why jj makes it easy

jujutsu models change identity separately from commit hashes. Rebasing the stack forward is a single command; the stack as a whole is queryable; conflicts that arise mid-stack live in commits, not in a special workflow state.

Where it shows up

The workflow is increasingly common because AI coding agents produce more parallel work in flight than human-only teams used to. See agent-principal-agent-problem (Crawshaw on review-effort collapse) for the upstream effect — once it's cheap to produce small PRs, the next bottleneck is whether your tooling can manage a stack of them.

Tooling that supports stacked PRs today:

• gh-stack — GitHub CLI extension for managing stacks via gh.
• Graphite — commercial stacking tool, external metadata store.
• git-spice, git-spr, and several smaller utilities.
• jj-native workflows (no extra tool required).