[HN Gopher] Stacked PRs are now live on GitHub
___________________________________________________________________
Stacked PRs are now live on GitHub
Author : tomzorz
Score : 445 points
Date : 2026-07-30 16:26 UTC (8 hours ago)
HTML web link (github.blog)
TEXT w3m dump (github.blog)
| tao_oat wrote:
| 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.
| theappsecguy wrote:
| 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.
| perspectivezoom wrote:
| I will second git-spice. It does exactly what you want and,
| importantly, no more than that. There's no upsell to anything
| else; it's "just" a good tool that knows its purpose and
| boundaries.
| literallyroy wrote:
| How does git-spice compare to git-town?
| theappsecguy wrote:
| I haven't used git-town, but from a cursory look it appears
| to be a various collection of gitops improvements for day
| to day things, including some for stacking.
|
| git-spice is specifically targeted to be useful for PR
| stacking and doesn't require you to do anything differently
| from normal git operations that you likely use already. It
| has a bunch of really nice flows and doesn't try to step
| outside the bounds of what is needed to easily stack PRs
| camilomatajira wrote:
| I have been using it for a while and it has been useful. One
| feature that I am still missing is to be able to stack PR across
| repositories. In other words, I want this stack to contains some
| PRs to the backend, some to the front, and some to ArgoCD in some
| specific order.
| jeremy_k wrote:
| Been using it over the last week. Only complaint I had was that
| `gh stack rebase` was struggling rebasing after squash merges but
| I got a response that the rebasing had been improved so I'm
| looking forward to trying that out.
| lucky_cloud wrote:
| Is that why the menu toggle is the stack of pancakes emoji
| (U+1F95E)?
|
| Whimsy is fine but that change made me super suspicious about
| what I was looking at.
| ebrahimh wrote:
| For a moment, I thought it was a reddit-style account birthday
| badge
| robin_reala wrote:
| Yes: https://github.com/orgs/community/discussions/203497
| sameenkarim wrote:
| We've been using the pancake emoji internally so we thought it
| was a fun easter egg. It'll only be up for a few hours and then
| will go back to the regular icons :)
| cebert wrote:
| Good. This change was unexpected and so unprofessional I
| though my browser was compromised.
| hext wrote:
| You thought your browser was compromised? Pathetic.
| themanmaran wrote:
| My lord people accept a little bit of whimsey in your
| lives.
| Waterluvian wrote:
| Remember when the Internet was a culture? Now you attempt
| the most tame possible attempt at that culture and people
| go into the Issue tracker to throw their little fit.
| Shish2k wrote:
| Funnily enough the two features that I've missed from
| phabricator are Stacked Diffs and the per-user opt-in
| whimsy mode, maybe GitHub can copy the latter next? :D
| petepete wrote:
| You should give Azure DevOps a try!
| patte wrote:
| I was so happy when I saw that! There is joy and silliness
| left in GitHub! Thank you!
| Waterluvian wrote:
| I liked it. It's nice to have little fleeting moments of what
| I call "Classic Web" feel.
| hungryhobbit wrote:
| Both GitHub and GitLab have recently released new stacked MR
| tech: I guess everyone is submitting giant AI-authored PRs these
| days, and there's a real need to break them up into human-
| reviewable chunks.
|
| Both are an improvement (GH's seems a little better, with their
| one-button merge that GL lacks) ... bit both are so incredibly
| "meh".
|
| When are we going to see the major hosts give tools designed to
| help facilitate human code review? Simple example: lets say I
| want to leave notes in my PR (MR on GitLab). I can use the review
| comments to do so, but then I have a million comments to resolve
| at the end before I can merge, my comments look just like the
| reviewer comments (with extra UI for replying that's unecessary),
| etc.
|
| It'd be so easy to just have a "sign post" feature to let authors
| annotate their code before reviewers review it ... and nobody
| offers this, or any other features focused on actually helping
| humans review. It's all just new command line features that save
| a bit of rebasing (which Claude can do just fine on its own).
| jaredsohn wrote:
| Or even just let me make a thread in github without associating
| it with files / a line of code. I hate it when conversations
| span top-level messages.
| efromvt wrote:
| Praise be, stacking is such a better ux for separating out a
| feature diff into distinct component units and native support
| makes it easy.
| piyushsingariya wrote:
| Finally. Something we got
| 8260337551 wrote:
| Rejoice, finally a new feature that isn't AI related.
| smoll wrote:
| Not AI related, but I plan on having my agents use this heavily
| so I can review PRs in bite-sized chunks instead of all at
| once.
| techscruggs wrote:
| I get your point, but it kind of is AI related. The size of PRs
| since AI has made it much harder to review a diff. Stacking the
| PRs seems like a response to this problem.
| amethyst wrote:
| We were benefiting from stacked pull requests in Phabricator
| for a decade before "AI" was a thing. Having well scoped
| commits that can be individually actioned by distinct sets of
| reviewers has always been extremely useful.
| IshKebab wrote:
| It definitely isn't. People have wanted this for many years.
| It's an obvious workflow. There's been a feature request
| since at least 2020 and I'm sure there were earlier ones:
| https://github.com/cli/cli/issues/2693
| dmix wrote:
| This is definitely connected to AI. High code volume, bigger
| PRs.
| sepeth wrote:
| One of the nice things about jujutsu related to this is that when
| you update a branch, it rebases other branches started off of
| that branch. I often switch to jj if I want to split my work for
| easy reviewing, and it works great colocated with a clone created
| with git.
| yes_but_no wrote:
| also jj absorb is amazing, it will move your changes to nearest
| relevant changes so addressing a thing that might effect
| different pr s is pretty easy
| matharmin wrote:
| I've been using the preview for a bit, and I'm quite surprised to
| see them expanding the preview with so many unfixed issue.
|
| For example, merging an entire stack is completely broken in many
| cases: https://github.com/github/gh-stack/discussions/212
|
| You can merge one by one, but if you're using squash and merge,
| you need a re-approval for each PR in the stack if you require
| reviews. This makes you lose out on arguably the biggest gain of
| stacked PRs.
|
| The command line tooling (gh stack) helps to make things slightly
| less manual, but you still need to be very aware of how git
| rebase works, the tooling just helps automate it across multiple
| branches. For example, just running the "gh stack rebase"
| commands that the UI suggests won't work if your local branches
| are not in sync with the remote ones, and the tooling won't point
| that out to you.
|
| I do find the stack UI quite nice. It's quite minimal compared to
| standalone PRs, but it's enough to show the relationship between
| them.
|
| (My comments all assume you already have a good reason to stack
| PRs. This tooling just help to make the workflow easier, it does
| not give any new capabilities)
| sameenkarim wrote:
| We're rolling out a series of bug fixes for the issues with
| squash merging.
|
| There's an internal system we have called CPRMC (Create Pull
| Request Merge Commit) that is used to evaluate whether a PR is
| "ready" to merge. This covers everything from mergeability
| (checking for merge conflicts) to rule evaluations (ensuring
| that approvals match the potential commit that will be created
| by merge) and more.
|
| This becomes particularly difficult when squash merging a stack
| of multiple PRs because we have to calculate a series of
| squashed commits, then associate those back to the
| rules/reviews. This is relatively easy for the first PR, but
| for the second PR onwards this gets more complicated because
| the ancestor commits are squashed and don't exist on the branch
| as-is. And I won't get into how much more complicated it gets
| for multi-parent situations lol.
|
| It's something we need to fix and it's the top priority for the
| team. Our numbers show that 99% of stack merges go through
| successfully, but we need to get that much higher.
|
| Thank you for being an early user in the preview and bearing
| with us while we work out these issues!
| masklinn wrote:
| > There's an internal system we have called CPRMC (Create
| Pull Request Merge Commit) that is used to evaluate whether a
| PR is "ready" to merge. This covers everything from
| mergeability (checking for merge conflicts) to rule
| evaluations (ensuring that approvals match the potential
| commit that will be created by merge) and more.
|
| By the way could there be a way to disable that when doing
| integrations externally? It seems to be quite costly (which
| makes sense), and the pull/ refs kinda bloat the reflist.
|
| I'm sure that external integration is not exactly beloved
| internally but there's really just a small handful of big
| annoyances which would make it so much nicer and more
| comfortable.
| Game_Ender wrote:
| Can you make sure there is good API support for stacks?
|
| We use a custom merge queue and we want it to be able to land
| multiple PRs from a stack at once as separate PRs. Last I
| checked you had to land a single PR, rebase the stack, land
| the next and so on. This is very expensive in CI time (and
| wall clock time), vs simply testing part or all of a stack in
| parallel then declaring those merged. In essence a robot
| needs the ability to say "squash merge these 3 stacked PRs",
| after the queue does its thing.
| sameenkarim wrote:
| Yes that was one of our top priorities. For one, there's a
| fully public API for all stack operations. So if you don't
| want to use the `gh stack` CLI, you can build your own:
| https://docs.github.com/en/rest/pulls/stacks
|
| For merging, we have an API but had to move it to a new
| async method: https://github.github.io/gh-
| stack/reference/merge-api/
|
| The legacy API was fully synchronous, and since stacks of
| multiple PRs can often take more than 10s (our global
| timeout), we had to move to async.
|
| We've had some folks already use this to integrate stacks
| into their merge queues. The great part is you can land
| multiple PRs in one atomic operation, and then there's one
| push to main with all your commits from multiple PRs. So
| instead of having to rerun the build/deploy for each, it
| can trigger for the last commit that contains all of the
| changes.
| mattmatheson wrote:
| Hey there - we worked with Sameen and the team at GitHub
| over the past month to get support for stacks in our
| Mergequeue: https://trunk.io/blog/trunk-merge-queue-now-
| supports-github-...
|
| They do indeed have APIs you can use in your mergequeue,
| I'm happy to share notes on how we built it so you can add
| it to your mergequeue.
| selimthegrim wrote:
| what if you stack a draft PR on top of a regular one?
| sameenkarim wrote:
| The draft one can't be merged, but the one below it isn't
| affected and can be merged as long as it's green. The
| dependency goes bottom-up.
| ransom1538 wrote:
| If you thought git was complex, wait until you get your 5 deep
| stacked PR from that nice coworker! Jokes aside this is really
| an anti-feature. Now coworkers can blow off your PR for much
| longer.
| keeganpoppen wrote:
| hahahah yeah my company had sooooo many issues with this stuff
| and merge queue lately
| vermilingua wrote:
| You're surprised? Really? I'm more surprised that they pushed a
| major change and the site is still up.
| an0malous wrote:
| the whole industry has become completely "ready, fire, aim"
| since 2021
| mosura wrote:
| GitHub has been especially bad.
|
| Ultimately they have become a monopoly so it is kind of
| expected.
| zelphirkalt wrote:
| So many things on Github are now broken or utterly
| unusable, that this comment is not wrong. I mean even the
| code viewer/display is utterly broken and doesn't even
| perform standard text highlighting correctly. The folding
| marks often make no sense or are inconsistent. If one wants
| to see all forks of a repo, one has to go through
| "insights", I think few would suspect it to be located, and
| it doesn't show _all_ forks, according to the number
| displayed next to the fork button. The list of UI issues
| goes on and on. But then there are also the reliability
| issues, things being down every 2 weeks, or is it every
| week by now? Difficult to keep up with it really.
| hobofan wrote:
| We just today ran into a bug where if the branch a stacked PR
| points to is deleted, it can just stay stuck in "merging"
| without any additional feedback. I directly looked at the GH
| status page, because who knows, maybe the PR subsystem has a
| partial outage again, but no, it was just a bug in the stacked
| PR feature.
| sameenkarim wrote:
| Thanks, definitely sounds like a bug. Will look into this.
| saghm wrote:
| > For example, merging an entire stack is completely broken in
| many cases: https://github.com/github/gh-stack/discussions/212
|
| > You can merge one by one, but if you're using squash and
| merge, you need a re-approval for each PR in the stack if you
| require reviews. This makes you lose out on arguably the
| biggest gain of stacked PRs.
|
| I'm struggling to imagine what it offers _at all_ if that doesn
| 't work! Is it just a way of manually marking another MR as a
| dependency in the UI so that it shows up with a red X if the
| other one isn't merged yet?
| OJFord wrote:
| Spicy opinion: a reinvention of commits by and for people who use
| commits like 'File > Save'.
|
| ...but if the end result is more popularity of 'stacked' logical
| changes, yay anyway?
| Okkef wrote:
| 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 where diffs & comments are
| intertwined, a bit like how "Literate Programming" intertwines
| code and prose.
|
| Literate diffs / literate pull requests... I haven't found
| anything like that yet.
| dastbe wrote:
| > 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 grow with size of the feature
|
| Another distinction is the ability to focus each part of the
| stack to a particular audience. One change may require review
| from an external team, another may be just your team mate, a
| third might be the consuming team. By focusing the stack to the
| different reviewers you can avoid ambiguity about "what a
| person is signing off on" in the stack.
|
| aside: one thing that would be great for github reviews is the
| adoption of change ids such that comments persist across
| reviews with a rebase workflow.
| skydhash wrote:
| 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, they could have been split. And if they're not, I
| would really like to know how the part that I'm reviewing
| interacts with the rest of the changes.
| a_t48 wrote:
| The PRs may be orthogonal but still be dependent. Feature X
| depends on improvement Y which also needs bugfix Z. You
| might go and implement X in a branch, tweaking the codebase
| as you go, but split the branch apart for review. You put
| X/Y/Z up, but X contains Y and Z, which means you can't
| request reviews for X without Y and Z merging, or else have
| a bunch of extra code that gets in the way.
| skydhash wrote:
| Let's say that Z has an error (some assumption that does
| not hold), and needed to be reverted. How does that
| impact X's viability? I wouldn't trust any reviews of X
| after that.
|
| I strongly believe that PR should be compared to the main
| branch, and not rely on unmerged code. Unless you merge
| everything together in one go. And in the latter case,
| everything should be reviewed together.
| a_t48 wrote:
| I think the answer is - it depends! This is why we make
| good money. I don't think there's a hard and fast rule
| here to apply.
| makeitdouble wrote:
| If the tooling allows rollbacking X, Y and Z as a set, it
| could make sense ?
|
| I'm also on the "compare to the main branch" camp in
| general, but will sometimes end up with a set of X,Y,Z
| branches that have different purposes but all depend on
| X.
|
| More often than not, the base dependency is a set of
| constants or additional class/methods that could be
| released with no impact (no reference in live code) but
| still need a somewhat lenghty review process. Reverts
| would be happening on the higher level PRs, which
| hopefully are independent.
| dastbe wrote:
| > That can be easily done with comments. If the PR are
| orthogonal, they could have been split.
|
| Comments are ad-hoc and don't scale, relying on the author
| to interpret and adhere to the extent of the reviewers
| approval.
|
| > And if they're not, I would really like to know how the
| part that I'm reviewing interacts with the rest of the
| changes.
|
| you are free to look up, down, and around the stack; nobody
| is hiding the code from you. But in many cases this is just
| unnecessary.
| madeofpalk wrote:
| it's basically a UI for a well-curated set of commits, and
| reviewing per commit.
| Cedricgc wrote:
| With stacking you can continue working on a longer change while
| creating reviewable diffs. Merged diffs can be rebased on your
| HEAD. For teams that support stacked diffs you don't usually
| even need to manage branches and work directly off trunk and
| rebase changes as they come in
| hoppp wrote:
| I think it is designed for AI Pull Requests. My impression was
| that it's for reviewing large generated changes.
| EduardoBautista wrote:
| I feel it's more of a limitation of the GitHub UI. It is much
| easier to group together reviews and comments by PR than it is
| by commits.
| mmlb wrote:
| 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.
| skydhash wrote:
| > 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.
| steveklabnik wrote:
| You can't have mac/windows/linux/whatever all locally
| simultanously.
|
| Not every project requires this, but for those that do,
| it's impossible.
|
| Also, it is much harder to enforce "everyone must run each
| commit through the CI equivalent properly" than it is when
| it's on your forge.
| skydhash wrote:
| > You can't have mac/windows/linux/whatever all locally
| simultanously.
|
| Why can't you? That's what VMs are for. And even then,
| most cross-platform codebases have an abstraction layer
| that rarely changes. So even testing on one platform can
| raise your confidence very high.
|
| > Also, it is much harder to enforce "everyone must run
| each commit through the CI equivalent properly"
|
| Again why? I wouldn't care about the dev's local branch.
| But what is send to the main repo can be easily scripted
| to run the CI on every commit. You just send the result
| back with each commit that fails. They can replicate the
| same workflow on their local workspace as a pre-push
| process.
| steveklabnik wrote:
| You can't run MacOS in a VM on non-Mac hardware without
| violating Apple's EULA.
|
| > But what is send to the main repo can be easily
| scripted to run the CI on every commit.
|
| Sure, this could work. I didn't say it was impossible,
| just more difficult. You have to build all of this
| support on top of the system that already does it for
| you: have your forge run CI on every commit.
| sfink wrote:
| Heh, it's a fun reminder that different people work on
| different things.
|
| Sure, I could load up my build machine with
| mac/windows/linux/android, with multiple versions of
| each. Emulating x86+x86_64+arm32+arm64+aarch64+... is
| also doable, sort of.
|
| But considering that the real CI runs several thousand
| hours of tests total across all platforms, I think I
| won't.
|
| Also, my Electron-based IDE needs those 10s of GB to edit
| text. How can you possibly edit a 1KB text file with less
| than 1GB of RAM?
|
| Not to mention clangd that needs to do its ultra-
| important work Right Now so I can invalidate it all with
| my next edit. That's probably the biggest RAM hog of them
| all.
| nijave wrote:
| >Can't you run your CI locally?
|
| If you mean automated tests and linters, sure.
|
| Conceptually continuous integration is generally
| integrating 2+ different lineages of code together which is
| more common with multiple developers although I suppose
| it's becoming more relevant with agents creating a bunch of
| worktrees with different things.
|
| In practice, CI has taken the same path as "DevOps
| Engineer" ie most people just mean "automated test server"
|
| The opposite of CI is more-or-less merge windows or merge-
| fest like Linux where everyone mails in their changes and
| someone manually integrates.
| happimess wrote:
| > Conceptually continuous integration is generally
| integrating 2+ different lineages of code together
|
| > In practice, CI [often means] "automated test server"
|
| Could you say more? I use "CI" to refer to the automated
| processes that run tests and (maybe) deploy code as it is
| merged to some blessed branch. It's what continually
| integrates the new code into the existing code. What am I
| missing?
| satvikpendem wrote:
| I don't get it, we already have CI for each commit, at least
| at our workplace, enforced.
| tabwidth wrote:
| Other side of that though, touch the bottom of a stack and
| every layer above it re-runs. Stack unwinding, basically.
| teeray wrote:
| It's the "well-curated" part. Many folks treat commits like
| video game save points, and find providing any kind of message
| burdensome (e.g. "fix bug", "do work"). This alone is fine, but
| then they can't be bothered to go back and clean it up with
| `git rebase -i`, so you end up with a mountain of trash in your
| git log if you don't turn on mandatory squash and merge. For
| these folks, the PR becomes the commit. Stacked PRs is
| revolutionary because it's as though these developers can
| finally have multiple commits which comprise a change.
| eddythompson80 wrote:
| > (e.g. "fix bug", "do work")
|
| or "skjdnfks" and "fsdfs" commits.
| chillfox wrote:
| There is real value in having all the messy commit history,
| especially now with AI, but you do need some kind of
| description on them that indicates what they are.
|
| One use I have got from it is asking an agent to go through
| the git history and categories the mistakes/bugs, then turn
| the common ones into CI checks or AGENTS.md rules.
|
| A well curated history just hides a lot of valuable info.
| dualvariable wrote:
| > What's the benefit of this type of stacked PRs over a well-
| curated set of commits, and reviewing per commit?
|
| What I can see is that you can easily append commits to e.g.
| the first PR in a stack, which would insert them into the
| middle of sequence of commits.
|
| This will require rebasing and fixing the subsequent PRs in a
| stack the same way you'd need to rebase and fix the subsequent
| commits in a mega-PR. But it makes the right thing easy
| (keeping all the commits to the foundation of the change
| together) rather than makin the wrong thing easy (appending
| fixup commits across the entire change in a random order so
| that the actual foundational change is lost).
|
| Keeping all the foundational commits together also keeps all
| the discussion over the foundational change together.
|
| You could argue that you'd want to only do the foundational PR
| and stop, but doing the whole stack of PRs gives the reviewers
| more information about where you're going, and allows work to
| continue asynchronously.
| paxys wrote:
| You can't merge one commit at a time in a PR. In a stack, if
| the first 4 parts of a feature are good to go and there's a
| problem with the 5th, the whole thing doesn't need to be
| blocked.
| ahepp wrote:
| I wonder if they could have added the ability to take only
| certain commits from a PR though?
|
| It kinda seems like they're duplicating the "unit of change"
| arbitrarily, rather than just fixing the way a PR works.
|
| I think the reason I find that a bit icky is it seems like
| it's diverging GitHub from the underlying git tool, which I
| trust a lot more.
| mcintyre1994 wrote:
| The issue you'd have then is the CI might not be green
| after the 4th commit but it is after the 5th. A single PR
| will hide that, so you'd need a way to run the CI on the
| subset of commits you want to extract. It's also much
| easier to isolate those blocking comments on the 5th commit
| if it's in its own PR and not mixed with all the review
| comments on the other ones.
|
| I don't really see it as diverging much from the underlying
| git tool TBH - it's still just git branches pointing at
| each other.
| paxys wrote:
| It isn't arbitrary. A branch is the unit of change. You can
| stack branches on top of each other and merge them one at a
| time. You can also keep adding to the end of the stack as
| needed.
| IshKebab wrote:
| 1. Github's UI doesn't really support reviewing individual
| commits in a big PR.
|
| 2. It also can't merge subsets of commits from a single PR.
| E.g. if you have two commits, A and B, where B depends on A...
| sure you can make a PR containing A and B, but if A gets
| approved and B doesn't, then you can't merge A.
|
| 3. The thing you want to do with a set of commits and reviewing
| each commit _IS_ stacked PRs.
|
| This is nothing to do with AI.
| aeturnum wrote:
| I would say that it makes it easier to design a PR and then go
| back and update that PR as things evolve. For instance, you
| might decide you need one table so your first PR in the stack
| adds that table. But then you finish up with 2 or 3 more PRs
| and you get reviewed and you and your colleagues decide to add
| a 2nd table. Now you get to go back to that first PR, add the
| 2nd table and then you get to cleanly review that 2nd table.
| Then each PR in the stack also gets a clean small addition to
| handle the table, that can be reviewed in its own context with
| smaller diffs.
|
| So the idea is you can much more cleanly isolate changes for
| large features.
| ahepp wrote:
| I don't have experience with the stacked PR workflow and often
| find myself asking the same questions you are.
|
| As far as I can tell, the biggest benefit of stacked PRs over
| just making a coherent series of commits, is that it might make
| it easier to start work on your second PR before you merge the
| first one?
|
| With human-in-the-loop coding, that sounds like it could lead
| to a lot of wasted work if the first PR gets substantial
| feedback. But with agentic coding, I can imagine how it might
| be desirable to keep the agent chugging while the first PR is
| under review.
|
| Interested in learning more about it and generally agree that
| AI is stressing the current review paradigms a lot of us are
| accustomed to.
| 332451b wrote:
| For me it's hard to imagine not starting on the second PR
| after submitting the first one, regardless of AI or stacked
| PRs. For focused work I find it important to avoid context
| switching, stay in the zone and keep everything in my head.
| Wasted work in comparison feels less significant to me.
|
| If review is fast I'd be switching back and forth between
| tasks throughout the day. If review is slow I might end up
| implementing a feature over the course of two weeks rather
| than two days. With reviewers in different time zones,
| limited time or doing their own focused work, it adds a lot
| of latency going back and forth for every PR rather than
| iterating on a stack of PRs.
|
| Personally I find the biggest benefit is that it lets both
| the author and reviewers work at the pace that works for
| them, with reduced context switching and latency.
| lnrd wrote:
| > What's the benefit of this type of stacked PRs over a well-
| curated set of commits, and reviewing per commit?
|
| Even if the reviewer does the review commit-by-commit, all the
| comments and discussions will be on the same PR leading to
| multiple ongoing conversations about different topics that
| would be split if the PR are stacked. Also, all the new commits
| addressing the comments with spoil this commit-by-commit
| design, as the previous commits will be outdated and the new
| changes will be on top of those. I think it's beneficial for
| new changes to be a separate commit and not rewriting history,
| to not force the reviewers to re-read everything but just the
| latest changes.
| rrradical wrote:
| I thought 'stacking' PRs was useful in two circumstances.
|
| 1. The PRs are across different related repos, so they literally
| can't be combined into one PR.
|
| 2. You want to keep producing work while the first PR is in
| review. So you stack subsequent PRs onto the same branch.
| Basically just pipelining.
|
| But this feature doesn't seem to hit either use case, and instead
| just seems to be a different form of stacking commits into a
| single PR. The standard advice has always been to make atomic and
| meaningful commits (using e.g. rebase to tell a nice story for
| the reviewer). And reviewers can go through commit by commit if
| they like.
|
| What am I missing?
| piskov wrote:
| > 2. You want to keep producing work while the first PR is in
| review. So you stack subsequent PRs onto the same branch.
|
| Instead of using the same branch, make new branches from that
| parent and commit there.
|
| The cool thing about that approach is that (at least in git-
| tower app) is when you edit a parent branch after pr comments,
| all those new commits will be automatically "restacked" on
| descended branch (children branches will be rebased on new
| state or parent, incorporating the hew fixes)
| johsole wrote:
| Stacked PRs have been great, a huge boon for me. I was using it
| before the UI support, just on the command line. `gh stack
| rebase` is too useful.
| ymir_e wrote:
| Lately I've seen a lot of people complaining about GitHub
| downtime, performance and overall quality.
|
| Happy to see something in the right direction. I think they've
| woken up a bit. Still surprising how slow things can move at big
| companies.
|
| Companies like Linear, Vercel, Zed and Cursor all seem to be
| looking at GitHub more aggressively though. I do suspect there
| will be more competition shortly.
| Insimwytim wrote:
| I feel like many people (and industry in general) complicate
| things unnecessary. Stacked pull requests break
| large changes into small, reviewable pull requests.
|
| That's how pull requests are supposed to be, no? If yours aren't
| that - you ought to rewrite them. With stacks,
| you can independently review and check each pull request, then
| merge everything together in one click.
|
| Why would I want to do that instead merging (and
| deploying/testing) separately, which gives me more reliability?
| No more opening a single large pull request that takes forever to
| review, or splitting work across multiple branches you have to
| keep manually rebasing.
|
| Well, it doesn't seem like a simplification over dreaded "manual
| rebasing". And the target branch still moves, doesn't it? So, how
| are you "saved" from rebasing?
|
| It's like responsibility is shifted from the author to the tool.
| That has been tried before, and every time it seem to
| consistently produce a similarly shaped mess in a different area
| of a process, but with an added bonus of the tool's own problems
| and restrictions.
| tao_oat wrote:
| 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 navigating the
| GitHub UI is then annoying, I have to mentally keep track of
| where I am in the stack.
| mchristen wrote:
| Those could just be individual commits on a branch. Why does
| it need to be a stacked PR? That concept really only exists
| within the interfaces of these kinds of tools.
| andrewaylett wrote:
| They don't. But reviewing individual commits in the GitHub
| UI is hard.
|
| A set of stacked PRs is _exactly the same_ as a line of
| commits. The only difference is the UI, but the UI is the
| important bit here because _lack_ of UI is what 's stopping
| folk from doing that today.
|
| Even when I've developed my changes as a stack of commits,
| I'll feed them to my team one commit (and one PR) at a time
| so they're easier to review -- and I discovered that GitHub
| had turned on stacked commits UI because for one particular
| project I'd manually created a set of PRs in advance (with
| the right bases) and GitHub offered to create a stack out
| of them.
| 4lx87 wrote:
| > They don't. But reviewing individual commits in the
| GitHub UI is hard.
|
| So instead of solving that problem, GitHub developed
| tooling around a workaround for that problem (targeting a
| PR at another branch that also has a PR).
|
| Expanding reviews to allow per-commit reviews avoids the
| need for managing additional branches and all the
| headache that comes with it.
| andrewaylett wrote:
| Indeed. But lots of people have never even _heard_ of
| Gerrit :P.
|
| And the implementation feels very much like it sits in
| the UI layer, rather than further down the stack.
|
| I'm not trying to claim stacking PRs in this way is the
| _best_ way (it 's not). But it does add an extra
| affordance for those who want it without burdening those
| who don't with the need to understand why someone would
| prefer it.
|
| And there are also plenty of ways that people have been
| working around GitHub's (and to a lesser extent, git's)
| lack of tooling for working on changes in this way. I'm
| sure they have customers clamouring for the feature;
| whether they'll be happy with what they get remains to be
| seen.
|
| (Very happy jujutsu user here, my tooling makes it really
| easy to create stacked commits with a stable identifier
| that maps really easily to branches and then onwards to
| running `gh stack`, but what GitHub have delivered is
| _definitely_ still lacking)
| atq2119 wrote:
| The sad fact of life is that too many developers are used
| to pushing PRs with unprincipled commits, and relying on
| squash merges.
|
| The approach that GitHub chose can show those people
| almost immediate benefits, which is surely the better
| path towards adoption than trying to reeducate everyone
| to adopt a development flow based on clean rebases.
|
| And for those of us who do prefer clean rebases, the
| thing they built is still useful.
|
| A bunch of details aside, the major conceptual thing that
| the email based flow has which is still missing in
| GitHub's data model is the ability to have a discussion
| on the stack as a whole.
| esafak wrote:
| They could but they don't belong together. A PR should be
| about one thing. Refactoring one module for another's sake
| should be done in another PR. If not for reviewing, for
| revertability, and future debuggability.
| Insimwytim wrote:
| 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.
| malcolmgreaves wrote:
| A refactor and then a feature implemented on that refactor
| is tightly coupled by definition. It would not make sense
| to implement the feature and refactor independently,
| because you'd be wasting time implementing a feature that
| you would have to refactor again.
| pyth0 wrote:
| This is literally the point of stacked PRs. You implement
| the refactor in branch A, then branch B is created on top
| of that so you can implement your feature. Then you make
| separate PRs, one for merging branch A into main, and
| another for merging branch B into A. The GitHub feature
| just provides a nicer UX when interacting with such PRs
| by clearly showing dependency and allowing you to merge a
| stack together.
| kazinator wrote:
| I certainly don't want to see that in a one _commit_. A PR
| has one more more commits, though.
|
| The commits in a PR are already a stack of patches, and so
| PRs are already "stacked" as they are.
|
| If feature X depends on the refactoring (cannot be rebased on
| the un-refactored upstream), it's part of the change; you
| can't just merge the feature and not the refactoring.
|
| If the two _are_ separable that way then, sure, it makes
| sense to ask for them to be separate PRs.
| kazinator wrote:
| I also don't get it.
|
| > With stacks, you can independently review and check each pull
| request, then merge everything together in one click.
|
| Consider:
|
| "With pull requests, you can independently review and check
| each commit inside the pull request, and then merge the entire
| pull request in one click."
|
| Pull requests are stacked commits. This does not have to
| recurse; you don't need stacked pull requests, not to mention
| stacked pull request stacks.
|
| A commit can already contain changes to multiple files. In many
| cases, even a complex change can be just one commit. A sequence
| of multiple commits handles all the remaining cases.
|
| Stacked PRs sound like a use case for someone who never wants a
| PR to be a container for multiple commits, such that if a unit
| of work is best done as three commits, they want them in
| separate PRs. Oh, but now they are not related together, the
| way a stack of commits is related under one PR, so we need a
| meta-PR to contain PRs or something.
|
| This could be a consequence of commits being sort of second
| class citizens in the GitHub UI compared to PRs. If you want a
| commit to be treated as PR, on the same level, you must create
| a PR with nothing but that commit. So then, what would have
| been a single PR with four commits that you could merge with
| one click is now four PRs. Which you want to be able to merge
| them with one click.
| masklinn wrote:
| > With pull requests, you can independently review and check
| each commit inside the pull request, and then merge the
| entire pull request in one click
|
| Except you can't _really_ do that on GitHub, the "unit if
| review" is the PR so reviewing commits is adhoc,
| inconsistent, and awkward, and tracking their changes as they
| get fixed up is a pain. "Splatting" that as PRs is not the
| nicest way to do it green field, but it's an evolution that
| makes sense in GitHub's model.
| kazinator wrote:
| Right; so maybe that's the thing to fix.
| mrkeen wrote:
| I don't mind rebasing, so that's not really an issue.
|
| The problem I sometimes have is when I queue up 4 or 5 PRs in
| the afternoon and expect someone to take a look in the morning.
|
| The diff of A into master looks OK, but then the diff of B
| looks like AB, and the diff of C looks like ABC - each PR has
| changes that will have already been merged once earlier PRs
| have been accepted.
|
| My way around it was to raise E as a PR into D, raise D as a PR
| into C, etc. Then once approved, I change their destinations
| back to master for the actual merges.
|
| It really confuses reviewers though, even though it's meant to
| make it so they only see the appropriate changes.
| Chyzwar wrote:
| Lol, maybe they should first fix large PRs crashing/freezing UI.
| lucideer wrote:
| Started using the gh stack CLI when I first heard of this feature
| & really liked it - great tooling. Then got approved for the
| preview & found the corresponding web UI features incredibly
| underwhelming.
|
| Pre-approval the CLI tooling effectively enables easier
| automations around splitting a task into multiple atomic PRs -
| really great locally but then when you push they just show up as
| independent unlinked PRs.
|
| Post-approval... they still show up as independent PRs. There's a
| small nav drop down up top listing the other PRs in the stack but
| that's it. Literally no meaningful UI changes.
|
| The dropdown also allows you to perform a limited subset if the
| CLI functionality but this is similar to the ability to edit
| files in the UI - an optional extra casual use feature that won't
| be a part of dev workflows: the CLI (or IDE plugins I guess)
| would be the primary way to perform these actions.
|
| It all left me wondering what the big deal with the preview not
| being a general release - it's extremely minor optional UI. The
| stacks cli has been general release since this was announced.
| sameenkarim wrote:
| I hear you. We had to start with something a bit more minimal,
| but we are working on a much broader revamp for the PR UI. Part
| of that will include a persistent view of the stack so you
| always know you're working with a stack and easily navigate
| between the layers without a ton of clicks.
| _doctor_love wrote:
| I must be in a minority of some kind. I still think stacked PRs
| are the devil and a band-aid for org and process issues.
| wesselbindt wrote:
| Exactly, I feel the same way, and was surprised to see so few
| people pointing this out. Forest vs desert I guess.
| msalsas wrote:
| I don't see the point of this. Just keep your PRs small.
| pyth0 wrote:
| That is in fact the point of this. Split your large feature
| into smaller, more manageable PRs and have them still be
| connected within GitHub.
| sameenkarim wrote:
| Hey from the GitHub Stacked PRs team!
|
| Excited to release this more broadly so anyone can start
| stacking: https://gh.io/stacks
|
| Would love to hear any feedback, especially with the UI and CLI.
| We've got a lot more updates to the PR experience in store!
|
| Also happy to answer questions about the design decisions we
| made. There's a bunch happening behind the scenes, and it's one
| of the largest launches in GitHub history covering almost every
| service from Actions and protection rules to the CLI and mobile
| apps.
| leo60228 wrote:
| Is support for cross-fork stacked PRs coming in the near
| future? I was surprised that didn't come before the feature
| entered public preview, as it seems rather important for the
| feature to be useful on public repositories.
| sameenkarim wrote:
| Yes it will be coming! The reason it's taking a bit longer is
| because of the automated rebase that happens after you merge
| part of a stack. There are some legitimate security concerns
| because of this so multi-fork stacks (a stack which includes
| multiple different forks) are probably out of the question
| for now.
|
| We will support a stack that is fully contained within a
| single fork, where the entire stack targets the original
| repo.
|
| For example, a contributor who has a fork (user/buzz) of the
| original repo (org/buzz) could create the following stack:
|
| ``` frontend - PR #3 (base: user/buzz:api-endpoints) api-
| endpoints - PR #2 (base: user/buzz:auth-layer) auth-layer -
| PR #1 (base: org/buzz:main) org/buzz:main (trunk) ```
| RyJones wrote:
| This is the feature I've missed most from Gerrit. Thank you
| joenot443 wrote:
| Your team did an awesome job - I've been wanting this feature
| for years and what you guys delivered is exactly what I had in
| mind.
| lobofta wrote:
| I needed this feature! Thank you
| dogleash wrote:
| > Also happy to answer questions about the design decisions we
| made.
|
| Why did you choose extra pull requests as the division of work
| instead of building out a decent UI for
| reviewing/applying/reworking at the commit level? I assume
| there's some extra insight that made you ignore the mailing
| list "series of patches" workflow that inspired this whole
| thing and go with "series of series of patches" instead.
| hedgehog wrote:
| I like it based on initial testing today. I already use my own
| local UI for managing stacked PRs so I can see the dependencies
| as a tree view and the review + CI status for each, it would be
| good to also have those in the GH web UI. Maybe I missed it but
| it looks like merging just the bottom of the stack in the web
| UI might not be supported? Happy to share the workflow / code,
| it would be nice if it was supported within GitHub's native
| tools.
| miovoid wrote:
| Why not to make it part of Git project? Such fragmentation adds
| complexity and vendor locking.
| saghm wrote:
| Presumably because "vendor locking" is pretty much their
| entire business model
| mattmatheson wrote:
| Congrats Sameen and the rest of the team! Excited to see stacks
| make it into GitHub.
|
| We worked with Sameen over the last month to add support for
| GitHub stacks into our mergequeue, and I'm excited to announce
| support for it today: https://trunk.io/blog/trunk-merge-queue-
| now-supports-github-...
| sunshowers wrote:
| I apologize for being somewhat direct but what prior art did
| you engage with? Why are you making people create a branch for
| each change in a stack? Why do developers have to create new
| commits when iterating on the PR? Where is the proper support
| for interdiffs? What about change IDs?
|
| The fundamental issue with GitHub -- really, its original sin
| -- is that the review model is wrong. It encourages a new
| commit + merge workflow, which is simply worse than an amend +
| rebase workflow. Basically every other review system in
| existence -- Gerrit, Phabricator, what Google and Meta have
| internally, the LKML -- works around stacks where people amend
| and rebase their commits when changing them. All of these have
| some notion of a "diff", with "versions" that are each tracked
| separately, and the ability in the review tool to do diffs
| between those versions. My hope with stacked PRs was that _for
| once_ GitHub would use this as an opportunity to modernize its
| review system and bring it in line with all of these other
| ones. But sadly that just doesn 't seem like it's on the cards.
| ptx wrote:
| Doesn't GitHub do this already? If I force push the PR
| branch, the PR shows a message about this with a link to diff
| it against the previous version.
| sunshowers wrote:
| That is nowhere close to the experience Gerrit and
| Phabricator have, where you can diff two arbitrary versions
| in history. Comments on previous versions also get lost
| along the way.
| sefrost wrote:
| Personally I find this feature works 50% of the time, and I
| don't understand why.
| pavon wrote:
| IMO not using horrible opaque change IDs is one of the best
| parts of this. If I wanted it to work like Gerrit, I would
| just be using Gerrit.
| sunshowers wrote:
| You don't have to expose change IDs in the UI other than as
| a secondary thing! The current integer index would work
| just fine.
| steveklabnik wrote:
| This is one of the biggest changes to hit GitHub in many years.
| I'm really glad to see something like this deployed to one of the
| largest forges in the world, hopefully it will expose a lot of
| developers to workflows that they didn't even know about before.
|
| If you buy the idea that stacking produces better software, then
| this also has the opportunity to really help out quite a few
| people.
| thenewguy077 wrote:
| Another reason that increases the possibility of github's
| outages...
| pzmarzly wrote:
| Does it work across forks, or is it same repo only (like gh-stack
| et al)?
| cassidoo wrote:
| Currently same repo only, fork support coming soon.
| ligarota wrote:
| What the difference with just two PR with the second PR targeting
| the first one??
| jasonephraim wrote:
| I was wondering why there was a pancake icon in my GitHub menu
| https://github.com/orgs/community/discussions/203497
| santoriv wrote:
| The important question in the age of PR metrics as a yardstick
| for keeping your job:
|
| When you click merge, does a 3 stack PR show up as 1 PR in the Dx
| metrics or 3?
| bmitc wrote:
| The linked blob post says "public preview". That doesn't mean
| actually released or live, does it?
| paxys wrote:
| This is a huge feature if implemented well. Going from big
| organizations with their own custom-built versions of PR stacking
| back to vanilla GitHub was a huge productivity hit for me.
| yreg wrote:
| This page is unreadable for me (on iOS). The videos keep
| autoplaying and making themselves full screen.
| smb06 wrote:
| As one of my colleagues said - "only took them 5 years"
| zxspectrum1982 wrote:
| I don't like this.
|
| The case where I need stacked PRs is when I have a ton of changes
| and I want to upstream them. I have so many changes that I have
| probably written code in this order: 1. feature1 work 2. feature2
| work 3. architecture rework 4. docs 5. feature3 work 6.
| optimization 7. docs 8. feature4 work 9. security fixes 10.
| optimization 11. docs 12. last pass security fixes
|
| By the time I want to upstream, I probably want to reorder my
| commits and generate on PR per theme (arch, feature1 + docs +
| optimization, feature2+docs + optimization, etc) before I submit
| a bunch of PRs.
|
| GitHub stacked PRs solve none of my problems. Stacked PRs doesn't
| take care of the reordering of commits, it doesn't take care of
| rebasing changes, it adds very little on top of what I was
| already able to do by saying "this is PR 1 out of 7, this is PR2
| out of 7 and build on top of the branch that I used for PR1/7,
| etc".
|
| Hugely disappointing, bordering useless.
| IshKebab wrote:
| > it adds very little on top of what I was already able to do
| by saying "this is PR 1 out of 7, this is PR2 out of 7 and
| build on top of the branch that I used for PR1/7, etc".
|
| That's literally all it's supposed to do. Make that dev flow
| less awful so you don't have to say "by the way this PR depends
| on #123, I will change the target branch when that is merged"
| and nonsense like that.
| zxspectrum1982 wrote:
| Well, then it provides so little they could have not done
| anything at all as well. Useful stacked PRs would be
| something that uses AI to split my large branch/PR into
| smaller PRs for upstream to review. Claude does that for me.
| calumcl wrote:
| They've provided a skill with their stacking CLI to provide
| guidance to any coding agent and the Copilot harness now
| ships with a pr-stack command to do exactly what you're
| saying for PR splitting FYI: https://twitter.com/_JeremyMos
| eley/status/208219039710799469...
| shoyer wrote:
| When will this support "trees" of pull requests, with dependent
| changes? In my experience with stacked changes (from Google), it
| is often the case that changes do not stack up as a linear
| history. I imagine that would especially be the case these days
| with parallel coding agents.
| dmix wrote:
| That sounds difficult for a human to manage, are we sure we
| want software to encourage that? (and therefore AI)
| DDayMace wrote:
| It's good to have this feature, but it is still up to the
| individual developers to separate the PR work in a way that can
| be merged "all or some and in which order". It can make
| organizing, reviewing and rebasing easier but a PR with repeat,
| broken or overriding code can screw up just the same. I guess
| what I mean is, don't expect it to just sort out multiple PRs
| that wouldn't have worked together without it.
| qihqi wrote:
| inspired by https://github.com/ezyang/ghstack?
| ln809 wrote:
| Need to fix the darn font, reads like "stocks" here....
| hmokiguess wrote:
| Ah. That's why the pancakes!
| miovoid wrote:
| Why not to make it part of Git project?
| _--__--__ wrote:
| GitHub has about as much of a shot of doing that as I do of
| fixing my allergies by updating the base human genome.
| SEJeff wrote:
| RIP Gerrit
| andy_ppp wrote:
| I'm probably going to ask AI to break up my huge PR into a stack
| then with sensible names? Probably could be a skill?
| sfink wrote:
| https://searchfox.org/firefox-main/rev/878b64a4c024f657de81f...
|
| but note line 111:
|
| > This section describes what to do if you're in a Jujutsu (jj)
| repository. If the user is not using jj, good luck and try your
| best.
|
| (The whole skill kind of assumes jj. I think you'd need to make
| a git version if you actually wanted to use it.)
| byterivet wrote:
| This is one of the biggest changes to happen on GitHub in many
| years.
| ozozozd wrote:
| So, it was hard to review 1000 lines in one PR.
|
| And we solve this by splitting into 2 PRs that still merge at the
| same time. Oh, super useful!
|
| Only if your reviews are so shallow that you don't try to reason
| about the state of PR B merged to PR A, which would then be
| merged to main, and your real problem is just GitHub UI failing
| to handle a giant PR, which we all know that this feature is
| attempting to help with.
| cyanregiment wrote:
| You can already PR off another PR but ok.
|
| I do it all the time.
|
| It's just merging branches.
| chill_ai_guy wrote:
| Probably a few years too late on this. Its for a time when humans
| still reviewed PR's. For better or worse, that is a thing of the
| past. The review step has shifted heavily left and newer re-
| imagination of Git (like Origin) will almost certainly not have a
| concept of a "PR" let alone stacking them
| zelphirkalt wrote:
| I remember having tried these on Gitlab a few years ago. One PR
| depending on another, depending on another ... It didn't
| ultimately make for a good experience. Partly that was due to
| Gitlab's interface, but also it wasn't necessary to complicate
| PRs even more.
___________________________________________________________________
(page generated 2026-07-31 01:00 UTC)