Cursor Origin
Stacked Diffs in Cursor Origin: The Review Model
A stacked diff is a series of small, dependent code changes, each built on the one below it, reviewed as separate pull requests instead of one large one. It is Graphite's signature workflow, run through the gt CLI, and the review model Origin inherits from the Graphite team that builds it.
On this page
What is a stacked diff?
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."
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Each PR is reviewable on its own. The stack records what depends on what.
How do you work in stacks with the gt CLI?
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.
- gt create
- Makes a new branch stacked on the current one and commits staged changes. An --ai flag can generate the branch name and commit message.
- gt submit
- Force-pushes every branch in the stack and opens or updates one pull request per branch.
- gt restack
- Rebases dependent branches so each one keeps its parent in its history after you change something lower in the stack.
Commands and flags per Graphite's command reference (graphite.com/docs/command-reference).
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.
How is reviewing a stack different from one big PR?
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.
Graphite's docs say to turn OFF "dismiss stale approvals" and "require approval of the most recent reviewable push." Both are designed for a single PR, and both will keep re-requesting review every time a lower change in the stack updates the branch above it.
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.
Why do stacked diffs suit AI-generated code?
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.
Stacked diffs, the gt commands and the review practice are confirmed on Graphite's own docs. The Origin-specific integration, native stacks, AI review inside Origin, a stack-aware merge queue, is expected from the team's history but not yet documented by Cursor for Origin.
Frequently asked questions
What is the difference between a stacked diff and a normal pull request?
A normal pull request is one branch of changes reviewed as a unit. A stacked diff is several dependent branches, each its own pull request, where each builds on the one below it. You review and merge them in order from the bottom of the stack, which keeps each review small.
Do I need Origin to use stacked diffs?
No. Stacked diffs are Graphite's workflow and run today through the gt CLI against GitHub. Origin is built by the Graphite team, so stacked review is expected to be central to it, but you can adopt stacks now without waiting for Origin.
What does gt restack do?
It rebases the dependent branches in your stack so each one still has its parent in its git history after you change something lower down. It automates the manual rebasing that would otherwise make stacks painful to maintain across several branches.
Sources & last verified
- Graphite — Benefits of stacked diffs
- Graphite — gt command reference
- Graphite — Reviewing stacks
- Cursor — Origin (waitlist)
Cursor ships frequently. Facts verified against primary sources on June 26, 2026.