Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by lucky_cloud - I think it's telling how long it took GitHub to release a v1 of this feature. Folks have wanted this for a long time. Graphite came along and did it years ago (and I'm sure they pondered whether GitHub would do this).
And the v1 is also a bit... basic, and buggy. And I'm surprised there's not clear documentation for agents (given using GitHub stacked PRs CLI won't be in models' training data yet).
It does feel like GitHub hasn't been great at shipping new features for a few years now. Nonetheless, I'm glad to see this rolling out. Once polished, it's going to be exciting to use.
by m11a - I feel like many people (and industry in general) complicate things unnecessary.
That's how pull requests are supposed to be, no? If yours aren't that - you ought to rewrite them.Stacked pull requests break large changes into small, reviewable pull requests.
Why would I want to do that instead merging (and deploying/testing) separately, which gives me more reliability?With stacks, you can independently review and check each pull request, then merge everything together in one click.
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?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.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.
by Insimwytim - 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.
by steveklabnik - 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.
by sameenkarim - 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.
by Okkef - I dislike them reinforcing the component approach to delivering work through their examples, like the top screenshot showing "database schema changes", "api changes" and "frontend implementation" as separate branches in a stack.
So really, one does consider full stack a single feature, but unless they are reviewed in one go — which defeats the purpose of stacked branches and pull requests — you can end up landing one and a later review in branches higher in the stack needing changes in the lower branches even if they were already reviewed.
When you instead focus on full use-case per branch, but scope them down, it is much less likely you will need to change branches lower in the stack after they are reviewed.
Another obvious use-case is to do a pre-emptive refactor, though I actually prefer doing a post-refactor after the new use-case has been merged in — it's much easier to know the target best approach when you've got your use-cases right in front of you (or you may hit a similar problem as above).
FWIW, I remember fondly using bzr-pipeline plugin to bzr VCS ~15 years ago to do exactly this.
by necovek - 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)
by matharmin