HN

Comments (370)

• Menu

  adamwk
  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).
• Menu

  jenadine
  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?
• Menu

  bsimpson
  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.
• Menu

  akersten
  Does it fix the current UX issue with Squash & Merge?Right now I manually do "stacked PRs" like this:main <- PR A <- PR B (PR B's merge target branch is PR A) <- PR C, etc.If PR B merges first, PR A can merge to main no problems. If PR A merges to main first, fixing PR B is a nightmare. The GitHub UI automatically changes the "target" branch of the PR to main, but instantly conflicts spawn from nowhere. Try to rebase it and you're going to be manually looking at every non-conflicting change that ever happened on that branch, for no apparent reason (yes, the reason is that PR A merging to main created a new merge commit at the head of main, and git just can't handle that or whatever).So I don't really need a new UI for this, I need the tool to Just Work in a way that makes sense to anyone who wasn't Linus in 1998 when the gospel of rebase was delivered from On High to us unwashed Gentry through his fingertips..
• metafeather
  I've been using `git town`[1] for years to managed stacked PR's alone with Github PR's[2] and juniors I have introduced it to have really found it a helpful mental model when developing features.I hope the Gitub CLI will include syncing[3] 'stacks' locally with upstream in a similar way.[1]: https://www.git-town.com/stacked-changes.html[2]: https://github.com/marketplace/actions/git-town-github-actio...[3]: https://www.git-town.com/commands/sync.html
• Menu

  cleverdash
  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.
• Menu

  AJRF
  I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.
• netheril96
  Does this work from a fork? That is, can I file a stacked PR to a project not owned by me, by creating branches in my forked project? Previously I asked AI about how to contribute stacked PR, it told me that I can only do it when I have push privileges to the repo, not from a fork, and the doc here is ambiguous.----OK, I found this from official docs, so this feature is now quite useless to me:> Can stacks be created across forks?> No, Stacked PRs currently require all branches to be in the same repository. Cross-fork stacks are not supported.
• Menu

  fphilipe
  I've been doing stacked PRs for ~2 years now. Thus, I don't quite see the need for this CLI. Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of.My biggest gripe with GitHub when working with stacks – and something that's not clarified in these docs – is whether fast-forward merges are possible. Its "Merge with rebase" button always rewrites the commit. They do mention that the stack needs to be rebased in order to merge it. My workaround has been `git merge --ff-only top-branch-of-stack` to merge the entire stack locally into main (or anything in between actually) and then push. GitHub neatly recognizes that each PR in the stack is now in main and marks them all as merged. If there are subsequent PRs that weren't merged it updates the base branch.Having said that, it's great to see GitHub getting a proper UI for this. It's also great that it understands the intent that branch B that goes on top of branch A is a stack and thus CI runs against. I just hope that it's not mandatory to use their CLI in order to create stacks. They do cover this briefly in the FAQ[3], but it might be necessary to use `gh stack init --adopt branch-a branch-b branch-c`. On the other hand, if that removes the need to manually create the N PRs for my stack, that's nice.[1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase...[2]: https://github.com/tummychow/git-absorb[3]: https://github.github.com/gh-stack/faq/#will-this-work-with-...
• Menu

  robertwt7
  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
• Menu

  WhyNotHugo
  I really don't get the point of stacked PRs.Just using git, you'd send a set of patches, which can be reviewed, tested and applied individually.The PR workflow makes a patch series an undivisible set of changes, which must be reviewed, tested and applied in unison.And stacked PRs tries to work around this issue, but the issue is how PRs are implemented in the first place.What you really want is the ability to review individual commits/patches again, rather than work on entire bundles at once. Stacked PRs seems like a second layer of abstraction to work around issues with the first layer of abstractions.
• boomlinde
  IME the github workflow promotes bad commit hygiene by making squashing or rebasing as-is an either-or choice in the web GUI.This will help some since you can more easily split PRs into units that make sense to squash at the end, but it still seems like not doing this on a per-commit basis is a disadvantage compared to Gerrit. With Gerrit I can use all the built-in Git rebase/squash/fixup tools to manage the commit stack and push everything in one go. I don't think there's a nearly as convenient a way to work with stacked branches in Git.
• Menu

  thcipriani
  Very cool that GitHub actually put stacks in the UI vs. GitLab's `glab stack`[0] (which looks just like the `gh stack` part of GitHub's thing).One part that seems like it's going to feel a little weird is how merging is set up[1].That is, if I merge the bottom of the stack, it'll rebase the others in the stack, which will probably trigger a CI test run. So, if I have three patches in the stack, and I want to merge the bottom two, I'd merge one, wait for tests to run on the other, merge the second vs. merge just those two in one step (though, without having used it, can't be sure about how this'd work in practice—maybe there's some way to work around this with restacking?)[0]: <https://docs.gitlab.com/cli/stack/>[1]: <https://github.github.com/gh-stack/guides/stacked-prs/#mergi...>
• Menu

  herpdyderp
  I thrive on stacked PRs but this sure seems like a weird way to implement support for it. Just have each branch point to their parent in the chain, the end. Just native Git. I've been longing for better GitHub support for this but the CLI is not where I need that support: just the UI.
• Menu

  fweimer
  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.
• Menu

  conor_f
  This just reeks to me of bad practice. Why use this as opposed to breaking your change into smaller PRs and merging them individually behind a feature flag or similar? With this, you have a marginally better UX for reviewing through the Github website, but the underlying issues are the same. The change being introduced is not sufficiently testable by itself, or it's (somehow) too tightly coupled to other parts of the UI/codebase that it can't be split. You still need to test for integration issues at every point of the stack, and some architecture issues or points of code reuse can't be seen from stacked changes like this.Not for me, but I'm glad it fits other people's workflows. I just hope it doesn't encourage people to try make poorly reasoned changes!
• Menu

  dminik
  Maybe this is just a skill issue, but even with several attempts I just can't figure out why I would use stacked diffs/PRs. Though maybe that's because of the way I work?I notice a lot of examples just vaguely mention "oh, you can have others review your previous changes while you continue working", but this one doesnt make sense to me. Often times, the first set of commits doesn't even make it to the end result. I'm working on a feature using lexical, and at this point I had to rewrite the damn thing 3 times. The time of other devs is quite valuable and I can't imagine wasting it by having them review something that doesn't even make it in.Now, I have been in situations where I have some ready changes and I need to build something on top. But it's not something just making another branch on top + rebase once the original is merged wouldn't solve.Is this really worth so much hype?
• Menu

  ninkendo
  > a chain of small, focused pull requests that build on each other — each one independently reviewable.I have never understood what this even means.Either changes are orthogonal (and can be merged independently), or they’re not. If they are, they can each be their own PR. If they’re not, why do you want to review them independently?If you reject change A and approve change B, nothing can merge, because B needs A to proceed. If you approve change A and reject change B, then the feature is only half done.Is it just about people wanting to separate logical chunks of a change so they can avoid get distracted by other changes? Because that seems like something you can already do by just breaking a PR into commits and letting people look at one of those at a time.I’ve tried my best to give stacked-diff proponents the benefit of the doubt but none of it actually makes sense to me.
• quibono
  GitLab's UI around MRs (PRs) is IMO miles better than what GH's been offering. Try creating a PR from branch A to main, and then rebasing A. GitLab handles this fine and can show you changes between the two revisions; GitHub is completely lost.
• Menu

  ZeWaka
  Seems to mainly be useful for monorepos as currently designed. Or, to replace a long-lived feature/refactor branch.
• Menu

  fmbb
  > Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops, and the whole team slows down.OK, yeah, I’m with you.> Stacked PRs solve this by breaking big changes into a chain of small, focused pull requests that build on each other — each one independently reviewable.I don’t get this part. It seems like you are just wasting your own time building on top of unreviewed code in branches that have not been integrated in trunk. If your reviews are slow, fix that instead of running ahead faster than your team can actually work.
• eqvinox
  > How It Works> The gh stack CLI handles the local workflow […]That's not "how it works", that's "how you['re supposed to] use it"… for "how it works" I would've expected something like "the git branches are named foo1 foo2 and foo3 and we recognize that lorem ipsum dolor sit amet…"…which, if you click the overview link, it says "The CLI is not required to use Stacked PRs — the underlying git operations are standard. But it makes the workflow simpler, and you can create Stacked PRs from the CLI instead of the UI." … erm … how about actually explaining what the git ops are? A link, maybe? Is it just the PRs having common history?…ffs…(In case it's not obvious: I couldn't care less for using a GH specific CLI tool.)
• Menu

  cadamsdotcom
  The vibecoded frontend makes the product look like a side project.Is it?
• jrochkind1
  Well, I have been waiting for this for YEARS.Every time I try to do it manually, I wind up screwing everthing up.Very interested ot check it out.
• Menu

  inerte
  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->CHere'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).
• mhh__
  I think the core conceptual difference between a stacked diff and PRs as we use them in open source is the following:A PR is basically a cyberspatial concept saying "I, as a dog on the internet, am asking you to accept my patches" like a mailing list - this encourages trying to see the truth in the whole. A complete feature. More code in one go because you haven't pre-agreed the work.Stacks are for the opposite social model. You have already agreed what you'll all be working on but you want to add a reviewer in a harmonious way. This gives you the option to make many small changes, and merge from the bottom
• Menu

  topaztee
  how is this different than viewing a PR one commit at a time?
• Menu

  alkonaut
  Let's say I have the canonical example of a stack from main via a backend-pr and a frontend-pr. When my stack is done I send it for review to one frontend reviewer and one backend reviewer.Usually when you develop a "full stack" thing you continuously massage the backend into place while developing frontend stuff. If you have 10 commits for frontend and 10 for backend, they might start with 5 for backend, then 5 commits to each branch to iron out the interface and communication, and finally 5 commits on the frontend. Let's call these commits B1 through B10 and F1 through F10. Initially I have a backend branch based on main wuth commits B1 through B5.Then I have a frontend branch based on B5 with commits F1 through F5. But now I need to adjust the backend again and I make change B6. Now I need to rebase my frontend branch to sit on B6? And then I make F6 there (And so on)?And wouldn't this separation normally be obvious e.g. by paths? If I have a regular non-stack PR with 20 commits and 50 changed files, then 25 files will be in /backend and 25 in /frontend.Sure, the reviewers who only review /frontend/* might now see half the commits being empty of relevant changes. But is that so bad?
• j3g6t
  Super excited to give this a whirl - i've been messing with graphite's `gt` command for stacking and it's been relatively decent but I didn't love needing to bring in another tool/service/account when I only care about the stacking behaviour. Was a fun experiment but nice I can simplify back onto `gh` and `git`
• rs545837
  This is awesome honestly, Stacked PRs are one of those features that feels obvious in hindsight. Breaking a n-line PR into 3 focused layers where each one is independently reviewable is a huge win for both the author and reviewer. The native GitHub UI with the stack navigator is the right call too, and there's no reason this should require a third-party tool.One thing I keep thinking about in this same direction: even within a single layer of a stack, line-level diffs are still noisy. You rename a function and update x call sites, the diff shows y changed lines. A reviewer has to mentally reconstruct "oh this is just a rename" from raw red/green text.Semantic diffing (showing which functions, classes, methods were added/modified/deleted/moved) would pair really well with stacks. Each layer of the stack becomes even easier to review when the diff tells you "modified function X, added function Y" instead of just showing changed lines.I've been researching something in this direction, https://ataraxy-labs.github.io/sem/. It does entity-level diffs, blame, and impact analysis. Would love to see forges like GitHub move in this direction natively. Stacked PRs solve the too much at once problem. Semantic diffs solve the "what actually changed" problem. Together they'd make code review dramatically better.
• nonoesp
  First thing that came to mind was git butler.
• MASNeo
  Very curious about this as especially with more use of AI in the development process I have seen PR size has increased. So looking forward to general availability.
• sbinnee
  Is this going to be a part of triage task? If so, it makes sense. Whether a human developer or an AI made a big PR, AI goes review it and if necessary makes stacked PRs. I don’t see any human contributors using this feature to be honest because it’s an extra work and they should have found a better way to suggest a large PR.
• baalimago
  Sounds like a merge-conflict nightmare
• zmmmmm
  Curious how / how well it deals with conflicts in the different branches that are part of the stack. Is there some support for managing that, or what happens when two of the branches don't rebase / merge cleanly?
• sailorganymede
  Thank goodness. It was a pain to do this manually
• pbrowne011
  Interesting to see how their CLI compares with GitLab's CLI interface for stacked diffs (the only support they offer at the moment): https://docs.gitlab.com/user/project/merge_requests/stacked_.... Most things are the same (up/down/top/bottom vs. next/prev/first/last, init vs. create), but both feel quite limiting. I've heard of other systems such as Gerrit that offer better native support, but have not tried out any for myself.
• Menu

  meric_
  I loved using sapling / mercurial so much at work that I ended up using the sapling SCM vsc extension at home all the time for personal work.Only downside is that Phabricator is not open source so viewing it in most things sucks. Hoping now I can get a much better experience
• atq2119
  People have been building stacked PR workflows on top of GitHub for a while now. It's great to see that the message seems to have finally landed at GitHub, but what is actually new here in GitHub itself (i.e., not counting the gh CLI tool)?There seems to be a native stack navigation widget on the PR page, which is certainly a welcome addition.The most important question though is whether they finally fixed or are going to fix the issues that prevent submitting stacked PRs from forks. I don't see any indication about that on the linked page.
• zeafoamrun
  My main question about this is does it keep review history properly after a rebase to restack PRs? Eg if I have reviewed PR for branch A and now its been rebased onto B by this tool and then more changes are made to A, does "review changes since" work in A's PR? This has been the main thing stopping me from wanting to use rebase to stack PRs and if they've fixed this somehow then I'm interested.
• Menu

  siva7
  What a time to be alive. Stacked PRs are now a native feature of Github, even with first-class support for your ai agents. Vibeslop your whole Jira Backlog. Don't fear the merge anymore. Just make any feature branch a long-lived branch by stacking one upon another like bricks.I'm old enough to have worked with SVN and young enough to have taught engineers to avoid stacking PR in Git. All wisdom has been lost and will probably be rediscovered in another time by another generation.
• Menu

  altano
  The `gh stack` CLI sounds essential for people using git, but I hope it doesn't become required, as people using things like jj/sl should be able to work with stacks. `gs submit`/`gs push` being the interface is fine, but `gs init` and `gs add` should be optional.
• K0IN
  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.
• mhh__
  1. Finally. Pull requests are consanguine and bizarre.2. I'm not a huge fan of having to use a secondary tool that isn't formally a layer around git / like jj as opposed to github
• Menu

  zzyzxd
  One mistake I see across many organizations is that sometimes they overthink how much order should matter.Sure, your application has a dependency on that database, but it doesn't necessarily mean you can't deploy the application before having a database. If possible, make it acceptable for your application to stay in a crashloop until your database is online.
• solaire_oa
  Pretty cool to see stacks being given due attention. Also check out git-spice, which works with Gitlab (possibly others). Personally I use git-spice in place of all the conventional git commands.
• jwpapi
  This is probably driven to be more usable with AI agents, but smaller prs can create more code as they need to enforce more backwards compability, this can also lead to more code or more maintenance work.Honestly I don’t see the benefit of smaller prs, except driving vanity scores?Like I’m not saying you should
• chao-
  Even though moments where I would reach for it are rare, this is a very welcome feature. In times when I could have used it, it was not difficult to emulate via more branches, consistent naming, referencing the PRs, etc. Not difficult, but definitely tedious, and always left me feeling less organized than I like to feel.
• jamietanna
  Very much looking forward to getting this on Renovate - we require squash-merge via Merge Queue (with no per-PR override available in GitHub, despite asking) and so when I've got multiple changes, it's a lot of wrangling and rebasingIf this works as smoothly as it sounds, that'll significantly reduce the overhead!
• srvaroa
  This feature is 10 years late
• prakashn27
  Meta has something similar to this using mercurial. It was awesome.
• throwatdem12311
  Freaking finally.I’ve been trying to convince my boss to buy Graphite for this, seems like Github is getting their a* in gear after Cursor bought them.If Jetbrains ever implements support for them in IntelliJ I will be in Heaven.
• baq
  Just when I’ve gotten used to having 3 or more PRs in parallel with a local octopus working tree with jj. Maybe my colleagues will see the light at least.
• lopsotronic
  Interesting to see how this integrates with any release flows that use a lot of tags or feature flagging.
• anon
  undefined
• Menu

  silverwind
  This needs to be supported on `git` level first imho, not by a forge vendor.
• mc-serious
  great, I'll directly compare it to graphite.com - the main point really is the user interface in my opinion. Still a bit sceptical whether github can out-deliver here, but happy to be proven wrong!Has anyone already tried that was a graphite user before?
• Menu

  ghighi7878
  What's difference between stacked PRs and merge trains in gitlab?
• ruined
  man, why is this waitlisted. this should have been a feature 10 years ago
• anon
  undefined
• lpeancovschi
  this was released about 7 years ago, no?
• latentdream
  the Website for the release statement look soooooo bad
• scottfits
  cherry picking is so fragile, this is at least a step in the right direction
• Menu

  teaearlgraycold
  Wondering how all of those startups that implement this for GitHub feel right now.
• godzillafarts
  “You cannot merge a PR in the middle of the stack before the PRs below it are merged.”Huh? Some stacks need to land all at once and need to be reviewed (and merged) from the top down. It’s not uncommon, in my org at least, to review an entire stack and merge 3 into 2 and then 2 into 1 and then 1 into main. If 2 merges before 3, you just rebase 3 onto 1.
• Menu

  whalesalad
  At first I thought this was a user submitted project due to the subdomain of github.com but then realize the subdomain is also github. Is this an official channel for this sort of thing? Surprised this isn't on the official blog.
• Menu

  inetknght
  Cool. Now let me do it across multiple repos. I often end up with 10 or 20 PRs across a half dozen repos that need to be merged in specific order.
• jen20
  I'm surprised no-one has commented on the "sign up for the waitlist" button being a Microsoft Office form that wants your email address and GitHub handle. This feels like an elaborate phishing attack more than a serious feature announcement.
• Pxtl
  This feels like a workaround for git's contradictory ergonomics.
• ChrisArchitect
  Aside:> This is a docs site that was made to share the spec and CLI for private preview customers that ended up getting picked up. This will move to GitHub docs once it’s in public preview.(https://x.com/matthewisabel)
• DesiLurker
  what happened to the old gerrit reviews, I loved its handling on incremental patchsets. github is primitive by comparison.
• Menu

  enraged_camel
  The biggest challenge for us are PRs that need to be coordinated across multiple repos. API + client for example. It doesn't sound like stacked PRs solve that problem, right? Description specifically states single repo.
• Menu

  noident
  If only there were some way to logically break up large pull requests into smaller pieces... Some way of creating a checkpoint with a diff including your changes, and some kind of message explaining the context behind the change... some way to "commit" a change to the record of the repository...
• the_gipsy
  Can we merge from GitHub UI without rewriting the commit already?
• jiusanzhou
  [dead]
• sparin9
  [dead]
• Menu

  sameenkarim
  [dead]
• jollife
  [dead]
• Menu

  TZubiri
  github.github.com? Not the first time github does something highly weird with their domains (like publishing docs from a subdomain of their public github pages service)I think they have a culture of circumventing 'official' channels and whoever is in charge of a thing is whoever publishes the thing.I think it's a great way to train users to get phished by github impostors, if tomorrow we see an official download from official.github.com or even official-downloads.github.io, sure it's phishy, but it's also something that github does.It's also 100% the kind of issues that, if it happens, the user will be blamed.I would recommend github to stop doing this stuff and have a centralized domain to publish official communications and downloads from. Github.github.com? Come on, get serious.TL;DR: DO NOT DOWNLOAD ANYTHING from this site, (especially not npm/npx/pnpm/bun/npjndsa) stuff. It's a Github Pages site, just on a subdomain that looks official, theoretically it might be no different from an attacker to obtain access to dksabdkshab.github.com than github.github.com. Even if it is official, would you trust the intern or whoever managed to get a subdomain to not get supply chained? github.github.com just think about it.
• Menu

  bob1029
  I feel like we already have enough abstractions in this space. Having any constraints at all in your tools is actually a good thing. PRs on top of ordinary git was a good step. This seems like one too many.