Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by lucideer - 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.by sameenkarim
- 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?
by rrradical - >1. The PRs are across different related repos, so they literally can't be combined into one PR.
This would be such a insanely useful features for a small subset of power users that they will never deliver.
by hypendev - > 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)
by piskov - 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.by tao_oat
- 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.by theappsecguy
- 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.by sepeth
- 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 easyby yes_but_no
- git rebase --update-refs
If one wants to keep it to vanilla git.
by Scoring6931 - Yes, and in fact, JJ is much more than that. One of the other features I use quite heavily is that, in JJ, you can essentially check out multiple branches at the same time by just creating a local merge. JJ will keep your local merge updated as you rebase the branches it builds on. I have written about it here: https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/by sarthak-ag
- 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 - For a moment, I thought it was a reddit-style account birthday badgeby ebrahimh
- by robin_reala
- 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 :)by sameenkarim
- 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 - This feature was brought up amongst GitHub for years, possibly even a decade. And it was something that they didn't want.
It was new leadership back in October that decided to build this, so it took them 9 months or so. To be clear, I am not saying this is a long amount of time, they had a LOT of work to do to get it to this point, just being clear about timelines.
by steveklabnik - 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 - 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.
by mrkeen - This. I don't even GitHub-style pull requests. A mature, big and complex project like the Linux kernel is still being (happily) developed using small email-based patches. I really appreciate the decision made by Drew Devault in SourceHut <https://man.sr.ht/~ireas/guides/contributing.md> to follow this effective yet simple way of managing contributions. GH PRs encourage a bad habit of making large, complex and unrelated changes in a single PR (or even one commit). Mainly bad because it makes the review process overwhelming and inefficient.by mahmouds
- 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.
by tao_oat - 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.
by kazinator - 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 - How is this different than creating a feature branch off main then branching off that?by nonethewiser
- 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 - 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.by joenot443
- 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.by hedgehog
- This is the feature I’ve missed most from Gerrit. Thank youby RyJones
- 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.by leo60228
- I tried to look through this earlier.
Am I right this is only available through the CLI?
If so it’s a no go for me and my team. Which is too bad because it looks quite useful.
An addition ability I would love, which is a MUCH bigger feature and I recognize that, would be multi-repo stacks.
My company doesn’t use a monorepo, and I like that. But as we’ve been breaking monoliths sometimes a logical feature touches multiple repos.
Being able to have them all in a stack, each building on the previous logically though in different repos, would be amazing.
Maybe it should have a different name. PR Trains? PR Chains? IDK. But being able to have multiple projects in one logical review is the one benefit of a monorepo I’d like, and if I could get it a different way I’d love it.
by MBCook