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, and each depends on the change below it. The bottom of the stack branches off main, and everything above builds on it.

Stacks exist to fix the monolithic pull request. A 1,200-line change is hard to review well, so it sits, and then someone approves it without a real review. Graphite's argument is that self-contained segments let 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 people skip, and it matters. Every layer inherits your verdict on the one below it. If you read PR 4 first and ask for a different approach, the fix usually lands down at PR 1, and everything above it gets rebased and comes back to you. Reading bottom-up costs nothing and saves the author a restack you caused.

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

Of the three, gt restack saves the most work. When you change PR 2 near the bottom, every branch above it needs a rebase to keep the stack consistent. Doing that by hand across four branches is the tedium stacks get blamed for, and gt restack does it in one command.

Split a stack where the change already has a seam, not by line count. Each layer should compile and pass its own tests: a migration that stands alone, then a model that needs only the migration. Small size follows from that. A stack split by line count is hard to review, because its layers don't stand on their own.

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

Two things change. You review each pull request as if it were an independent change, and when you are tagged on several, you start at the bottom of the stack, closest to main, and work up. And if you stack with Graphite on GitHub, you relax two GitHub settings that fight stacks.

GitHub's own stacked pull requests handle one of those cases for you. Since GitHub's version became generally available on October 6, 2026, an unchanged stack that GitHub rebases after main moves keeps its approvals, even where a repository dismisses stale approvals.

Switching off dismiss stale approvals means giving up a real control, so decide it openly instead of clicking through. You lose the guarantee that an approval refers to the exact code that will merge. You gain a stack that stops re-requesting review every time a lower layer moves. If your change-management policy names that setting, write down the compensating control before someone asks for it. The enterprise question list is where that conversation tends to start.

Stacks have a cost. Splitting one change into five PRs adds coordination, and a reviewer sometimes has to connect the pieces across the stack to see the whole change. Graphite's position is that smaller, faster reviews are worth that overhead. That often holds for a team that opens many changes a day, but it is still a trade.

Weigh head-of-line blocking first. A stack lands in order, so a reviewer on vacation under PR 1 holds up four finished changes above it. Your choices are to wait, or to take the finished changes out of the stack and reopen them on their own. A single large pull request fails differently: it also sits, but as one thing, with nothing 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.

If review is already quick and changes are already small, keep the workflow you have.

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, a chore that multiplies when changes are small and frequent.

Origin has stacks of its own now. Origin's CLI reference has you build a stack from the bottom: open the lowest pull request, then open each child with origin pr create --stack-on pointing at its parent. Basing one branch on another isn't enough, because Origin tracks each pull request's parent. Origin doesn't rebase branches unless you ask: run origin stack restack to rebase locally, or origin stack restack-remote to have Origin rebase the stack's open pull requests. Merging any pull request in a stack lands it together with every open one below it, as a single commit.