Stacked Diffs in Cursor Origin: The Review Model

Graphite defines a stacked diff as "a series of related code changes organized into distinct, incremental patches, each built on top of the previous one." Instead of one large pull request, you open several small ones, where each depends on the change below it. The bottom of the stack branches off main; everything above builds on it.

The problem this solves is the monolithic PR. A 1,200-line change is hard to review well, so it sits, and people rubber-stamp it. Graphite's argument is that breaking the work into self-contained segments lets a reviewer "grok a smaller patch without needing to mentally parse a broad swath of unrelated changes."

Reading order is the part of that diagram that gets ignored, and it is doing real work. Start at the bottom because every layer inherits your verdict on the one below it: read PR 4 first, ask for a different approach, and the answer is usually a change down at PR 1, after which everything above gets rebased and comes back to you. Bottom-up costs nothing and saves the author a restack you caused.

Graphite's command-line tool, gt, is what makes stacks practical. Three commands do most of the work, and they map directly onto how you'd build a feature in pieces.

The command that earns its keep is gt restack. When you change PR 2 near the bottom, everything above it needs to be rebased so the stack stays consistent. Doing that by hand across four branches is the tedious part stacks are accused of; gt restack is the answer to it.

Small is the wrong first criterion here, which is not obvious until you have reviewed a stack that someone split by line count. Self-contained is the criterion: each layer should compile and pass its own tests, so the cut falls where the change already has a seam, a migration that stands up alone and then a model that needs only the migration. Size comes out of that rather than driving it.

When CI fails on an upper layer after you have changed something lower down, check that the branch actually carries its new parent before you debug the test. A missed restack presents exactly like a broken change.

Two things change. First, you review each PR as if it were an independent change, and when you're tagged on several, you start at the bottom of the stack, closest to main, and work up. Second, you have to relax a couple of GitHub settings that fight stacks.

There is an honest cost to name. Splitting one change into five PRs adds coordination: a reviewer sometimes has to connect the pieces across the stack to see the whole. Graphite's framing is that smaller, faster reviews are worth that overhead. For most high-throughput teams it is, but it is a trade, not a free win.

Head-of-line blocking is probably the cost that decides this for most teams. A chain lands in order, so a reviewer on holiday under PR 1 holds up four changes that are otherwise finished, and the usual choices are to wait or to unstack the finished changes and reopen them on their own. A single large pull request fails differently. It also sits, but it sits as one thing, and nothing is queued behind it.

Stacks pay off in proportion to how large your changes would otherwise be. A team whose typical change runs a few hundred lines already has small reviews and mostly buys overhead here. A team that regularly opens a thousand-line pull request has the problem stacks were built for.

Where review is already quick and changes are already small, the workflow you have is fine.

Switching off dismiss stale approvals is a real control to give up, and it deserves saying out loud rather than clicking through. What you lose is the guarantee that an approval refers to the exact code that will merge. What you get is a stack that stops re-requesting review every time a lower layer moves. If your change-management policy names that setting, the compensating control needs writing down before someone asks for it, and the enterprise question list is where that conversation tends to start.

Agents already produce work in the shape stacks want: many small, related changes, fast. A single agent task often becomes a migration, then a model, then an endpoint, each depending on the last. That is a stack. And gt create --ai can name the branch and write the commit message, which removes a chore that multiplies when changes are small and frequent.

This is the clearest line between Graphite and Origin. Origin is built by the Graphite team, so stacked review is almost certainly central to it. How deeply Origin bakes stacks in, versus running gt against GitHub the way you can today, is the part to confirm when Origin ships.