Seems to mainly be useful for monorepos as currently designed. Or, to replace a long-lived feature/refactor branch.
bsimpson2026-04-14 05:48
ENGLISH (원문)
Finally! I never understood the PR=branch model GitHub defaulted to. Stacked commits (ala Phabricator/Gerrit) always jived more with how my brain reasons about changes. Glad to see this option. I guess I'll have to install their CLI thing now.
ezekg2026-04-14 05:50
ENGLISH (원문)
My only complaint off the bat is the reliance on the GH CLI, which I don't use either. But maybe by the time it's GA they'll have added UI support.
adamwk2026-04-14 05:55
ENGLISH (원문)
As someone who used phabricator and mercurial, using GitHub and git again feels like going back to the stone ages. Hopefully this and jujutsu can recreate stacked-diff flow of phabricator. It’s not just nice for monorepos. It makes both reviewing and working on long-running feature projects so much nicer. It encourages smaller PRs or diffs so that reviews are quick and easy to do in between builds (whereas long pull requests take a big chunk of time).
cleverdash2026-04-14 05:57
ENGLISH (원문)
As a solo dev I rarely need stacked PRs, but the underlying problem, keeping PRs small and reviewable, is real even when you're your own reviewer. I've found that forcing myself to break work into small branches before I start (rather than retroactively splitting a giant branch) is the actual discipline. The tooling just makes it less painful when you don't. Curious whether this changes anything for the AI-assisted workflow. Right now I let Claude Code work on a feature branch and it naturally produces one big diff. Stacked PRs could be interesting if agents learned to split their own work into logical chunks.
kardianos2026-04-14 05:59
ENGLISH (원문)
I continue to use gerrit explicitly because I cannot stand github reviews. Yes, in theory, make changes small. But if I'm doing larger work (like updating a vendored dep, that I still review), reviewing files is... not great... in github.
fweimer2026-04-14 06:03
ENGLISH (원문)
I find this puzzling. It does not seem to allow to stack PRs on top of other people's PRs? There is already an option to enable review comments on individual commits (see the API endpoint here: https://docs.github.com/en/rest/guides/working-with-comments...). Self-stacking PRs seem redundant.
dbbk2026-04-14 06:05
ENGLISH (원문)
If you visit the webpage it gives you integration instructions for agents
ameliaquining2026-04-14 06:08
ENGLISH (원문)
The tooling for that already exists, since a PR can consist of multiple Git commits and you can look at them separately in the UI. I don't know whether agents are any good at navigating that, but if not, they won't do any better with stacked PRs. Stacked PRs do create some new affordances for the review process, but that seems different from what you're looking for.
adamwk2026-04-14 06:10
ENGLISH (원문)
Maybe there’s a git trick I don’t know, but I’ve found making small branches off each other painful. I run into trouble when I update an earlier branch and all the dependent branches get out of sync with it. When those earlier branches get rebased into master it becomes a pain to update my in-progress branches as well
CharlieDigital2026-04-14 06:13
ENGLISH (원문)
This API leaves a comment, on the commit; not quite the same thing since in GH, several operations are tied to PRs and not to commits.
steveklabnik2026-04-14 06:20
ENGLISH (원문)
I have had a lot of success with Claude and jj, telling it to take the stack of work it's done and build me a new stack on top of trunk that's centered around ease of reviewing.
jannes2026-04-14 06:20
ENGLISH (원문)
Still feels like an alpha version right now. I'm sure they will add it later. Graphite (which they seem to be inspired by) has frozen branches exactly for that use case: https://graphite.com/blog/introducing-frozen-branches
jenadine2026-04-14 06:21
ENGLISH (원문)
I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is familiar with that) - ability to attach a comment to a specific commit, or to the commit message. - better way to visualize what change over time in each forced push/revision (diff of diff) Git itself already has the concept of commit. Why put this "stacked PR" abstraction on top of it? Or is there a difference I don't see?
robertwt72026-04-14 06:22
ENGLISH (원문)
There’s a startup callled Graphite dedicated to stacked PRs. I have been using them for a while now I always wonder why github doesn’t implement something similar to this. I probaly will try and switch to GitHub to see if it works flawlessly
K0IN2026-04-14 06:22
ENGLISH (원문)
Wow i really need this, we had a refactor our monorepo (dotnet 8 -> 10 and angular 19 -> 21) which resulted in many small changes (like refactoring to signals, moving components to standalone) and we try to group changes into commits by what was fixed, but this had the downside of some commits beeing huge while others small, this would have helped us alot grouping commits together and having cleaner commit messages.
smallmancontrov2026-04-14 06:24
ENGLISH (원문)
I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up being dog slow (always) or broken (some of the time). Git is fugly but it's fast, reliable, and fugly and I can work with that.
ghighi78782026-04-14 06:26
ENGLISH (원문)
What's difference between stacked PRs and merge trains in gitlab?
inerte2026-04-14 06:28
ENGLISH (원문)
Looks interesting, but it seems you need to know the final shape of the stack before you start creating Pull Requests. So it's useful if you create Pull Request A, then immediately start working on something that builds on top of A, create a Pull Request for that (while A is still a PR), then you can do A->B->C Here's something that would be useful: To break down an already big PR into multiples that make up a stack. So people can create a stack and add layers, but somehow re-order them (including adding something new at the first position).
tcoff912026-04-14 06:28
ENGLISH (원문)
It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently. It's really useful in larger corporate environments. I've used stacked PRs when doing things like upgrading react-native in a monorepo. It required a massive amount of changes, and would be really hard to review as a single pull request. It has to be landed all at once, it's all or nothing. But being able to review it as smaller independent PRs is helpful. Stacking PRs is also useful even when you don't need to merge the entire stack at once.
댓글
20