# 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).