Stacked PRs are now live on GitHub

Post by malcolmgreaves » Thu, Jul 30, 2026, 6:58 PM UTC

Insimwytim wrote: post #33

tao_oat wrote: post #26

Earlier quoted context omitted.

Here's a common flow where I find stacked PRs are useful: - I want to build feature X - Ah, but it would work better if I refactored the module first - I refactor then build feature X - There's then some additional (and optional) cleanup work As a reviewer I wouldn't want to see all this in a single PR, and the changes depend on each other so I can't open multiple independent PRs. Manual rebasing is fine but navigati…

I do that too. I do introduce changes in separate PRs. They could be related to the same problem and referenced accordingly. and the changes depend on each other so I can't open multiple independent PRs Why? Is it a technical restriction? Tightly coupled architecture is not the best solution anyway.

Post by teeray » Thu, Jul 30, 2026, 7:01 PM UTC

Okkef wrote: post #17

What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit? I think the bigger problem is that big AI PR's need a different way of reviewing. For example, the order in which the diff's are shown can make a big difference in how easy the commits are to read (e.g., function definition change first, then all call sites, then the tests). Or maybe we should go to a system w…

Post by literallyroy » Thu, Jul 30, 2026, 7:05 PM UTC

theappsecguy wrote: post #24

tao_oat wrote: post #2

Really excited to try this. After using Graphite it's been very hard going back to stack-less GitHub. Hopefully this can make the stacked PR workflow more common and give people an easier alternative to mammoth PRs.

I'd recommend git-spice, it's very easy to use and powerful, and of course open-source. I've tried graphite but found that they made it too convoluted for what it is.

Post by steveklabnik » Thu, Jul 30, 2026, 7:07 PM UTC

skydhash wrote: post #42

mmlb wrote: post #35

Earlier quoted context omitted.

I've had that same "what's the point" thought every time I've read about stacked PRs, but recently had an (obvious) epiphany. The benefit is you get CI for each commit! I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need.

> I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need. Can't you run your CI locally? I know it's not feasible for some codebase, but at least the linting, formatting, unit tests, some integration tests should be able to be done locally.

Post by a_t48 » Thu, Jul 30, 2026, 7:12 PM UTC

skydhash wrote: post #40

dastbe wrote: post #21

Earlier quoted context omitted.

> What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit? For the people who work with stacked diffs (in phab/otherwise) this is exactly what they'd consider reviewing a well-curated set of commits one-by-one. One distinction is that cognitively a unit of review (a PR, a diff) remains a single bound change. Comments are focused on that change and the PR does not gr…

IMO, in a team settings, improving the review policies and speed has a much better benefit. A PR is supposed to be a proposal for some change, adding more proposals on top of something that is not reviewed is a bit icky. > . By focusing the stack to the different reviewers you can avoid ambiguity about "what a person is signing off on" in the stack. That can be easily done with comments. If the PR are orthogonal, the…