Loading today’s stories
Build1 distinct publisher3 min readPublished
Stacked pull requests are still in public preview, and the command that creates them is not the command that updates them. What the extension does remove is the author-side coordination cost that made "make your diffs smaller" an argument rather than a workflow.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Small diffs benefit the reviewer and bill the author. That was the economics of the mandate before this extension: keeping a chain of contained branches meant a rebase and a force-push on each layer, one at a time, in order, every time the bottom changed [5]. Take a four-layer stack and edit the layer sitting on trunk. Three layers above it, each needing a rebase and a force-push, is six ordered manual operations before GitHub shows anything current [20]. The dev.to writeup by anchildress1 says they tried maintaining that by hand several times and does not recommend it [13]. `gh stack sync` is now one command for the same propagation [6].
The default worth checking first is the split between `sync` and `submit`. `sync` pushes branches and refreshes pull requests that already exist, and it has no create path, so a stack you have synced ten times still has nothing on GitHub until you run `submit` [6]. Documented, not broken, and exactly the shape that produces a confused message in the team channel on day one.
The conflict handling is good engineering. If two layers touch the same lines, `sync` stops on the conflict and restores every branch to where it was, so nothing is left half-rebased [9]. A five-branch chain frozen mid-rebase is worse than no chain, and the tool declines to hand you one.
Removing a middle layer is not in-place surgery. You run `unstack`, re-run `init` listing the branches you are keeping, then `submit`; `init` adopts branches that already exist, so commits, branches and open PRs all survive, and only the chain between them is thrown away [10]. Three commands where the metaphor implies one. The post describes trunk as the plate, each PR as a pancake, and GitHub as the thing managing the syrup between layers [23]; I am going to keep calling it rebasing.
Whether any of this shrinks review comes down to the merge rule. Whatever layer you are on merges everything from that layer down to the trunk [11]. Sit on the top pancake and one merge lands the whole stack [21]. So the split reduces the review surface per pull request without reducing what a single approval can ship. A team that approves the top layer because the ones below it are already green has made the diffs smaller and the merge exactly as large as before.
For the workflow to transfer you need `gh` installed and authenticated, push access to `origin`, and a clean tree on your trunk branch [8], plus reviewers who will actually read layer by layer. GitHub's docs frame the underlying problem as volume: large pull requests are difficult to review and create bottlenecks, especially when AI helps generate a high volume of code in a short time [3]. Splitting one large PR into four does not reduce the lines a human reads. It shrinks the unit and multiplies the count, moving cost into per-PR overhead such as review requests and repeated context loading. If reviewer attention is already saturated by that overhead, stacking makes the queue longer; if raw diff size was the blocker, it helps.
The feature is in public preview, so the edges will move [2]. The author, who has used it since the preview appeared in the GitHub UI a few weeks ago, calls it a game changer with kinks still to work out [14]. Their original complaint stands either way: substantial changes stopped shipping because "is this really required?" kept getting answered for them [12]. That answer is now cheaper to defend.
Ranked by verification strength, evidence, and original report placement.
gh stack is a GitHub CLI extension installed with `gh extension install github/gh-stack`.
Stacked pull requests are still in public preview, so users should expect the edges to move.
GitHub's documentation states: "Large pull requests are difficult to review and create bottlenecks, especially when AI helps you generate a high volume of code in a short time."
In a stack, every pull request targets the layer below it, with the trunk branch at the base.
Changing a lower layer used to require propagating upward with a rebase and a force-push, one layer at a time, in order.
`gh stack sync` pushes branches and refreshes pull requests that already exist, but it has no create path, so a stack synced ten times still has nothing on GitHub until `submit` runs.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 3, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
product
Cursor becomes a code host by default, and GitHub's seven outages in 15 days is the opening4 distinct publishers
build
rerere.autoupdate stages a replayed resolution before anyone checks it hit the right file1 distinct publisher
build
The kernel's Assisted-by trailer makes AI help a signed line, not a rumour1 distinct publisher
product
Copilot drops the flagship model, and the build record does not follow1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Reproducible commands, one witness
Almost everything here is checkable in five minutes at a terminal — the install line, the eleven subcommands, the view keybindings, the sync-has-no-create-path trap — which is why a single-source story holds this much weight. The exceptions are the two claims a reader can't cheaply test and that GitHub hasn't confirmed in this reporting: that a conflicted sync restores every branch untouched, and that unstacking and rebuilding leaves open pull requests intact. Those rest on one person's word.
Preview shipped, one desk using it
Two data points, both thin: GitHub put stacked pull requests into public preview a few weeks before publication, and one developer says he has lived in it since. No install counts, no second team, no organisation that has changed its review policy because of it. The author's own hedge — a game changer once the kinks are gone — is a fair description of where uptake stands.
Overstated, then walked back by the author himself
"Game changer" is doing more work than a few weeks on a preview feature can support, and the framing — one workflow ends a years-old argument about diff size — invites more than the evidence carries. But the same write-up supplies most of the correction: preview edges will move, sync silently creates nothing, the agent proposes layers but can't decide them, and Claude keeps forgetting the skill exists. Enthusiasm slightly ahead of proof, with the caveats printed rather than buried.
No vendor tie, but a graded metric in the background
Nothing suggests this author is paid by GitHub; he writes as a colleague addressing "work friends" and criticises the tool where it bites. The pressure is subtler and he volunteers it: his employer started grading file diffs per pull request, which puts a direct personal payoff on a tool that makes small pull requests cheap to produce. Add the ordinary reward for being early on a preview feature, and the enthusiasm has a reason beyond the code.
Trustworthy on mechanics, unproven on outcomes
We would bet on the command surface and the sync-versus-submit distinction; those are the parts a reader can confirm and the parts the author uses daily. We would not yet bet on the safety guarantees, on the workflow surviving contact with protected branches and busy review queues, or on any of it being stable while the feature stays in preview. One publisher, one repo owner, no independent check anywhere.