13 ms·

Stacked PRs are now live on GitHub

783 points by tomzorz 2mo ago

tao_oat 2mo ago
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 2mo ago
  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 2mo ago
    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 2mo ago
    How does git-spice compare to git-town?
    - theappsecguy 2mo ago
      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 2mo ago
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 2mo ago
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 2mo ago
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 2mo ago
  For a moment, I thought it was a reddit-style account birthday badge
- robin_reala 2mo ago
  Yes: https://github.com/orgs/community/discussions/203497 https://github.com/orgs/community/discussions/203497
- sameenkarim 2mo ago
  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 2mo ago
    Good. This change was unexpected and so unprofessional I though my browser was compromised.
    - hext 2mo ago
      You thought your browser was compromised? Pathetic.
    - themanmaran 2mo ago
      My lord people accept a little bit of whimsey in your lives.
      - Waterluvian 2mo ago
        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.
hungryhobbit 2mo ago
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 2mo ago
  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 2mo ago
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 2mo ago
Finally. Something we got
8260337551 2mo ago
Rejoice, finally a new feature that isn't AI related.
- smoll 2mo ago
  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 2mo ago
  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 2mo ago
    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.
    - PennRobotics 2mo ago
      Meh. Stacked PRs (where a PR is already a stack of commits, and reviewers can perhaps communicate with each other to coordinate scope/responsibility) are a bit like tab groups in the browser when tabs, multiple windows, and workspaces already existed for maintaining organization. This new feature clearly scratches an itch for some users but creates more complexity (yes, even if you don't interact with it) for people already comfortable with the status quo.
  - IshKebab 2mo ago
    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 https://github.com/cli/cli/issues/2693
- 2mo ago
sepeth 2mo ago
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.
- Scoring6931 2mo ago
  git rebase --update-refs If one wants to keep it to vanilla git.
- yes_but_no 2mo ago
  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
- sarthak-ag 2mo ago
  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/ https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/
matharmin 2mo ago
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 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 2mo ago
  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 2mo ago
OJFord 2mo ago
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 2mo ago
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 2mo ago
  > 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 2mo ago
    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.
    - 2mo ago
rrradical 2mo ago
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 2mo ago
  > 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)
- hypendev 2mo ago
  >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.
johsole 2mo ago
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 2mo ago
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 2mo ago
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 2mo ago
  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 2mo ago
    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 2mo ago
      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.
Chyzwar 2mo ago
Lol, maybe they should first fix large PRs crashing/freezing UI.
lucideer 2mo ago
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 2mo ago
  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 2mo ago
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 2mo ago
  Exactly, I feel the same way, and was surprised to see so few people pointing this out. Forest vs desert I guess.
msalsas 2mo ago
I don't see the point of this. Just keep your PRs small.
- pyth0 2mo ago
  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 2mo ago
Hey from the GitHub Stacked PRs team! Excited to release this more broadly so anyone can start stacking: https://gh.io/stacks 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 2mo ago
  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 2mo ago
    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) ```
    - doctorpangloss 2mo ago
      haha, what if you add a filter that hides merge commits? i appreciate that you are trying to make it possible for people who vibe code solutions to problems to get code merged by people who have made GitHub their lifestyle. but surely you see how, in my framing there, the people who are worried about how their history "looks" are the problem
- 2mo ago
cabyambo 2mo ago
[flagged]
steveklabnik 2mo ago
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.
- nonethewiser 2mo ago
  How is this different than creating a feature branch off main then branching off that?
  - shmichael 2mo ago
    Stack management: automatically rebasing all dependent PRs on any downstack change. Ability to view & navigate the stack in the reviewer UI. Ability to merge a whole stack with one command.
thenewguy077 2mo ago
Another reason that increases the possibility of github’s outages…
pzmarzly 2mo ago
Does it work across forks, or is it same repo only (like gh-stack et al)?
- cassidoo 2mo ago
  Currently same repo only, fork support coming soon.
lovetocode 2mo ago
Back in my day we called this feature branching
ligarota 2mo ago
What the difference with just two PR with the second PR targeting the first one??
jasonephraim 2mo ago
I was wondering why there was a pancake icon in my GitHub menu https://github.com/orgs/community/discussions/203497 https://github.com/orgs/community/discussions/203497
santoriv 2mo ago
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 2mo ago
The linked blob post says "public preview". That doesn't mean actually released or live, does it?
paxys 2mo ago
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 2mo ago
This page is unreadable for me (on iOS). The videos keep autoplaying and making themselves full screen.
smb06 2mo ago
As one of my colleagues said - "only took them 5 years"
zxspectrum1982 2mo ago
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 2mo ago
  > 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 2mo ago
    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 2mo ago
      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/_JeremyMoseley/status/2082190397107994698 https://twitter.com/_JeremyMoseley/status/208219039710799469...
shoyer 2mo ago
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 2mo ago
  That sounds difficult for a human to manage, are we sure we want software to encourage that? (and therefore AI)
  - charcircuit 2mo ago
    Coordinating 2 people working within a single linear stack is unnecessary overhead, even harder for humans to manage. It's easier to let them work off of a shared point individually.
- jezzamon 2mo ago
  You ideally need a directed graph where descendants can have multiple parents (which JJ supports). If you can't, then the linear tree is just as good I think. Say you do change A, add a protocol buffer API definition, then implement the server logic (B) and the front end code (C) so that both depend on A but not each other. That can be in a tree. But now you want to add an integration test (D) that depends on B and C. The tree doesn't help you there, and you were better off making it a linear chain by arbitrarily picking one of B or C to be dependant on the other so that you have a code state with all of A,B and C applied to create D on top of.
DDayMace 2mo ago
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 2mo ago
inspired by https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack?
ln809 2mo ago
Need to fix the darn font, reads like "stocks" here....
bogota 2mo ago
[dead]
sharpvik 2mo ago
[flagged]
hmokiguess 2mo ago
Ah. That's why the pancakes!
miovoid 2mo ago
Why not to make it part of Git project?
- _--__--__ 2mo ago
  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 2mo ago
RIP Gerrit
- SEJeff 2mo ago
  I found the single gerrit user, who downvoted me :)
andy_ppp 2mo ago
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 2mo ago
  https://searchfox.org/firefox-main/rev/878b64a4c024f657de81fb66a1e7de1aaad9109c/.agents/skills/reorganize-patches-for-review/SKILL.md 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 2mo ago
This is one of the biggest changes to happen on GitHub in many years.
fenestella 2mo ago
[flagged]
ozozozd 2mo ago
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 2mo ago
You can already PR off another PR but ok. I do it all the time. It’s just merging branches.
chill_ai_guy 2mo ago
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 2mo ago
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.
calmbonsai 2mo ago
As if GitHub wasn’t already unreliable enough. Fix. Your. Culture.
sitzkrieg 2mo ago
public alpha apparently. the concept of quality has not been present since years
necovek 2mo ago
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.
- nirvdrum 2mo ago
  Thanks for mentioning this. It seemed odd to me, too, so I spent some time trying to work it out. As a reviewer, I'm not sure how I'm supposed to assess database or API changes without knowing how they're intended to be used. And deploying them independently seems odd, too, especially if you need to roll it all back. I think in my ideal world there would be a clean history and I could review a PR commit-by-commit. But, you can't just approve a single commit, so there's a tooling problem there. And most CI runs on an entire push rather than individual commits. And increasingly I see devs using git as an offsite backup for whatever change they just made, rather than breaking commits up into logical chunks. In that workflow, squashed merges make the most sense. It's probably flawed, but the mental model I came up with is each stacked PR collapses into what would have been an individual commit in a clean PR, with the advantage of being able to be reviewed separately from the other changes and forced to clear CI. And then the whole stack becomes what would have been a clean PR in the old model. That, I can kinda see the benefit of. But, merging only part of the stack into trunk is the mental hurdle I can't clear; it'd be like merging only some commits from a PR. It kinda reminds me of when projects used CVS. I've really only seen stacked PRs used on projects where history is little more than an audit log. I'm keen to see how this gets employed by open source projects. I think there's a disconnect and it's likely I'm not going to really get it until I see it.
danpalmer 2mo ago
As someone who previously used GitHub a lot, and now works with stacked changelists (PRs) a lot, I'm not sure this really changes much. If there's an expectation that you might merge a whole stack, I think you're aiming for the wrong thing. And it seems like landing the whole stack is the biggest push GitHub are making here. Part of the point is independently reviewable and independently mergable. If you're going to merge in one go then just put everything in one PR and review commit by commit in that PR. The commit by commit review flow used to suck, but since ~2021 it has been fine. I feel like GitHub have built what users (who haven't used a true stacking system) asked for, not what they actually need to change their workflow for the better. A great implementation would be asking hard questions like: what's the role of a single commit? Should PRs be single commit only? What's the real benefit here? How do you encourage smaller units of review (because it doesn't look like this does).
- Kinrany 2mo ago
  Yeah: they copied what people were building on top of Github as a workaround to not being able to change Github
ankit84 2mo ago
Stacked PRs are not a new GitHub capability. They are an accessibility. Why so hype? The underlying stacked PR workflow is unchanged: 1. Create branch B from branch A. 2. Open PR A against main. 3. Open PR B against branch A. 4. Repeat for additional layers.
- zdc1 2mo ago
  I've been doing this for years. Maybe adding some UI sugar around it is nice, but it really shouldn't be that much of a big deal...
whichdan 2mo ago
The issue I have with stacked PRs isn't merging, but rather, when I change branch A, and I'm working on branch C, I then need to merge A into B and then B into C just to continue working. Collapsing/merging them at the end is the easy part.
threethirtytwo 2mo ago
Doesn’t this make it harder for an agent to review?
gsnedders 2mo ago
I’d still love a way to be able to rewrite commits at merge time, via Actions or otherwise. The most obvious case is something like adding a Reviewed-By/Signed-off-by trailer based on reviewers, but there’s also a decent number of big projects that want more semantically meaningful commit identifiers (think more revision, in a numeric sense). It seems like making merges async should make it a lot more possible to implement that!
DmitryO 2mo ago
Next.js is buggy shit. Bad example of usage))
bdubaut 2mo ago
Isn't this going to reinforce the long-lived branches anti-pattern? Large changes can be dangerous
Hypnosis6173 2mo ago
I would love to see more interactions from dev side in GH discussions rather than answering on HN. I think not responding anything there pushes the image of github not caring for the community
beaker52 2mo ago
Looking at the way GitHub are selling this “feature”, I feel like some of the engineers who are going to be excited about this feature for “reviewability” reasons are, in particular, those who’ve forgotten that they should be splitting changes into multiple logical commits inside a PR. And instead of that they’re now going to use multiple, single commit branches and stack them because stacked PRs are a “new” “feature”. And the upshot for the LLM providers is that they get to charge for n reviews, instead of one.
- eddythompson80 2mo ago
  I think plenty of people explained the difference between stacked PRs and individual commits in 1 PR. You’re not wrong, but it’s just a matter of path of least resistance. There is no way to leave a comment on a particular commit in a PR. Also all commits addressing PR feedback get tucked at the bottom of the commit list. Unless you do some crazy git gymnastics and rewrite the PR history and confuse everyone. With stacked PRs you also (as a maintainer or a reviewer) have the option to merge some and not others. Like here are 3 stacked PRs, one for provisioning some AWS or Azure resources that I’ll need, one for implementing the APIs using those resources, and one for updating the UI to use the new APIs. You can then say “let’s get the 2 backend PRs in and hold off on the UI as we’re changing that entire view”. You can’t do that with multiple commits in a PR without asking the person to redo the PR, then you’re back to git-foo. Yes, GitHub could have made the UI allow a “per commit” comments somehow, then allow you to select the set of commits to include in the merge somehow, then write a blog post on how to manage “Address PR comments #1” commits. But the stacked PRs solve all that. Not to mention how people treat commits as their own internal save states. I always enable “squash and merge” option because I think it makes a lot more sense to have 1 commit on main per PR where all the context of the change is either in the commit message or the linked PR. Also LLM providers charge per token. Charging per “work unit” is still not a solved problem. You can’t charge per “review” when your cost is per token. Just like airlines can’t charge “per ticket”, they have to charge differently depending on the destination. Unless you invent some bs arbitrage to lure users and eventually bait and switch on them.
- IshKebab 2mo ago
  Splitting changes into multiple commits is a much worse experience if you actually have self-contained dependent changes. 1. The whole review interface isn't set up for reviewing individual commits. 2. You can't merge changes progressively. 3. CI doesn't run on each commit. 4. If you have linear history (good idea IMO) you'll lose your nice commit history when you merge it. This is much better.
sarthak-ag 2mo ago
If your workflow is rebase heavy, I strongly recommend ignoring this github feature and using jj instead. I have written about my experience here: https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/ https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/
ivolimmen 2mo ago
I personally see no benefit using this. For large changes I often completely work locally until it's done. I commit everything logically and when everything is done I push and make one PR. The commits are not fully done as they work towards the main goal of the PR. If the team argues before the start of the feature that the individual commits are needed we split the ticket. This stacking sounds a lot like shit you need for shit made by LLM's
- eddythompson80 2mo ago
  The stacked PR pattern long predates LLMs. Yes LLMs make them more common and frequently steer you in that direction. But it’s by no means a new “LLM” thing. In the scenario you described of your team splitting the tickets, this gives you a UI to manage the PRs of the multiple tickets so you are no longer blocked on merging PR#1 before you can proceed to PR#2. Yes you might have to deal with conflicts, but you would have had to deal with that regardless.
grugdev42 2mo ago
I don't want this. It's too complicated. Plus it's vendor lock in. Give it time. Soon you'll only be able to push using Github's CLI.
- Shish2k 2mo ago
  Other platforms have been doing it this way for over a decade, and I've found stacked diffs (with Phabricator and Gerrit at least, not tried the GH version yet) to massively simplify my workflow o_O
fatwang2 2mo ago
Nice. The pain for me was never creating the stack, it was keeping reviews and restacks inside Github.
ben8bit 2mo ago
Honestly, I didn't even know this was a problem that needed to be solved.
m11a 2mo ago
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.
- deleted 2mo ago
  [deleted]
- steveklabnik 2mo ago
  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.
  - steveklabnik 2mo ago
    I can't add on to my comment because it's been too long, but a great thread on how much work this is: https://x.com/sameenkarim/status/2083237928092721646 https://x.com/sameenkarim/status/2083237928092721646
slaye 2mo ago
Is this open to regular users of a organization or only organization owners?
feiz45607 2mo ago
[flagged]
dysoco 2mo ago
Can someone explain to me what is the difference between whatever they added new and creating several PRs and "stacking" them by pointing one branch to another via the Github UI? I've always done that. Is it just a nice UI on top of that? Sure merging with one single button is nice but I rarely do that, if I'm stacking PRs it's because I probably want to merge gradually.
- jollyllama 2mo ago
  It's for people who don't understand long lived branches.
- jeltz 2mo ago
  Maybe it matters if you do not have the right to push to the main repo but still want both your PRs to live there. Is there a way to do that without stacked PRs?
skipants 2mo ago
This was the feature I wanted the most on Github... until I started using jj. I know that jj isn't for everyone, but for me it's been trivial to see the state of and update all the stacks of branches I have on the go. Not that I don't welcome this feature; I just think I don't need it anymore.
- Shish2k 2mo ago
  I am confused - I love JJ and stacked diffs with Gerrit and Phabricator, but trying to port that same "each commit gets reviewed individually, and things don't break when a half-reviewed stack gets rebased" workflow to GitHub has been a nightmare, how does JJ help?
pluc 2mo ago
You need some pretty big balls to deliver features when everyone is screaming about your availability
RomanPushkin 2mo ago
bye, graphite
RohoSwagger 2mo ago
dont know why you would use github stacked prs when you can just use ez-stack which has native worktree support and much more extensive functionality, also uses the stacked pr api https://github.com/rohoswagger/ez-stack https://github.com/rohoswagger/ez-stack
dml2135 2mo ago
I didn't see the appeal of bespoke PR stacking tools when it was the headline feature of Graphite, and I still don't see it now. Stacking PRs is useful, but I haven't encountered issues with the ergonomics of just using normal git operations to do it. My stacking workflow is roughly: - Open the first PR from `branch-1` against `main` - While waiting for a review on that first PR, if I need to build on subsequent work in `branch-1`, I'll `git checkout -b branch-2`, and open a draft PR against `branch-1` - If the open review requires me to make changes to make changes to `branch-1`, I'll `git merge branch-1` on `branch-2` to pull them up the stack - After `branch-1` is merged, my draft PR for `branch-2` will automatically update to being opened against `main` - Repeat as necessary depending on how much stacking is requires and how far ahead I get against my reviewers I don't find any of this all that difficult or cumbersome. Is there something that this feature offers, that I'm missing out on?
- lukaszkorecki 2mo ago
  That's how I worked but it gets tedious for reviewers because there's no easy way to navigate the stack. In the end, I vibe coded an internal PR stacker which stores stack data using `git notes` (allowing multiple people to work in a stack) and updates PR description with stack navigation. It uses merge, rather than rebase because history is not that important (final code is).
rbanffy 2mo ago
I used something similar to this while working for Canonical and I found the idea confusing, the tooling (2014, IIRC) brittle, and the experience overall frustrating. I would never encourage that as a solution to any problem. The most important thing about tooling is to keep it conceptually simple. The fewer moving parts you need to pay attention to, the more brain cells you can devote to solving your problem.
othmanosx 2mo ago
I've been using it for a while and I've actually shipped stacked PRs with github. we usually try to chunk the work so that we don't get in a situation were we have to open PRs with more 1k+ LOC, and we try to plan chunks of max 500 LOC, but I do find myself getting in this situation when the planned work turns out to be more than I anticipated like refactoring or edge cases or review feedback... etc. but that's where stacked PRs come in, I found that they could be useful in this situation to split an unexpectedly large PR into a few smaller ones that are chunkable, individually shippable, and easy to review. but that's where the good stuff ends IMO, stacked PRs just make a bad situation slightly better, and I think we shouldn't get into this situation in the first place. I know that can be impossible sometimes, but I already built my own solution for fix this problem. even though it's good to have, Github's UI doesn't help it, Github already sucks in terms of the review experience in a pull request and the implementation of the stacked PRs leaves a lot to be desired. thankfully, I was working on my own solution for this problem and I already integrated a better stacked PRs implementation compared to github, and I'm pretty happy with it. Pyor (pyor.review), I built it myself, sits on top of github, syncs everything with it, and gives me the benefit of having a better UI and code review experience.
mafo 2mo ago
I'm,in,already,now,live,on,github
mafo 2mo ago
'm,in,already,now,live,on,github
mafo 2mo ago
Show,job,sumit

783 points by tomzorz 2mo ago

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 2mo ago
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 2mo ago
  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 2mo ago
  How does git-spice compare to git-town?
  - theappsecguy 2mo ago
    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 2mo ago

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 2mo ago

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 2mo ago

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 2mo ago
For a moment, I thought it was a reddit-style account birthday badge
robin_reala 2mo ago
Yes: https://github.com/orgs/community/discussions/203497 https://github.com/orgs/community/discussions/203497
sameenkarim 2mo ago
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 2mo ago
  Good. This change was unexpected and so unprofessional I though my browser was compromised.
  - hext 2mo ago
    You thought your browser was compromised? Pathetic.
  - themanmaran 2mo ago
    My lord people accept a little bit of whimsey in your lives.
    - Waterluvian 2mo ago
      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.

hungryhobbit 2mo ago

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 2mo ago
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 2mo ago

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 2mo ago

Finally. Something we got

8260337551 2mo ago

Rejoice, finally a new feature that isn't AI related.

smoll 2mo ago
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 2mo ago
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 2mo ago
  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.
  - PennRobotics 2mo ago
    Meh. Stacked PRs (where a PR is already a stack of commits, and reviewers can perhaps communicate with each other to coordinate scope/responsibility) are a bit like tab groups in the browser when tabs, multiple windows, and workspaces already existed for maintaining organization. This new feature clearly scratches an itch for some users but creates more complexity (yes, even if you don't interact with it) for people already comfortable with the status quo.
- IshKebab 2mo ago
  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 https://github.com/cli/cli/issues/2693
2mo ago

sepeth 2mo ago

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.

Scoring6931 2mo ago
git rebase --update-refs If one wants to keep it to vanilla git.
yes_but_no 2mo ago
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
sarthak-ag 2mo ago
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/ https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/

matharmin 2mo ago

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 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 2mo ago
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 2mo ago

OJFord 2mo ago

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 2mo ago

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 2mo ago
> 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 2mo ago
  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.
  - 2mo ago

rrradical 2mo ago

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 2mo ago
> 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)
hypendev 2mo ago
>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.

johsole 2mo ago

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 2mo ago

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 2mo ago

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 2mo ago
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 2mo ago
  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 2mo ago
    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.

Chyzwar 2mo ago

Lol, maybe they should first fix large PRs crashing/freezing UI.

lucideer 2mo ago

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 2mo ago
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 2mo ago

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 2mo ago
Exactly, I feel the same way, and was surprised to see so few people pointing this out. Forest vs desert I guess.

msalsas 2mo ago

I don't see the point of this. Just keep your PRs small.

pyth0 2mo ago
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 2mo ago

Hey from the GitHub Stacked PRs team! Excited to release this more broadly so anyone can start stacking: https://gh.io/stacks 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 2mo ago
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 2mo ago
  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) ```
  - doctorpangloss 2mo ago
    haha, what if you add a filter that hides merge commits? i appreciate that you are trying to make it possible for people who vibe code solutions to problems to get code merged by people who have made GitHub their lifestyle. but surely you see how, in my framing there, the people who are worried about how their history "looks" are the problem
2mo ago

cabyambo 2mo ago

[flagged]

steveklabnik 2mo ago

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.

nonethewiser 2mo ago
How is this different than creating a feature branch off main then branching off that?
- shmichael 2mo ago
  Stack management: automatically rebasing all dependent PRs on any downstack change. Ability to view & navigate the stack in the reviewer UI. Ability to merge a whole stack with one command.

thenewguy077 2mo ago

Another reason that increases the possibility of github’s outages…

pzmarzly 2mo ago

Does it work across forks, or is it same repo only (like gh-stack et al)?

cassidoo 2mo ago
Currently same repo only, fork support coming soon.

lovetocode 2mo ago

Back in my day we called this feature branching

ligarota 2mo ago

What the difference with just two PR with the second PR targeting the first one??

jasonephraim 2mo ago

I was wondering why there was a pancake icon in my GitHub menu https://github.com/orgs/community/discussions/203497 https://github.com/orgs/community/discussions/203497

santoriv 2mo ago

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 2mo ago

The linked blob post says "public preview". That doesn't mean actually released or live, does it?

paxys 2mo ago

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 2mo ago

This page is unreadable for me (on iOS). The videos keep autoplaying and making themselves full screen.

smb06 2mo ago

As one of my colleagues said - "only took them 5 years"

zxspectrum1982 2mo ago

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 2mo ago
> 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 2mo ago
  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 2mo ago
    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/_JeremyMoseley/status/2082190397107994698 https://twitter.com/_JeremyMoseley/status/208219039710799469...

shoyer 2mo ago

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 2mo ago
That sounds difficult for a human to manage, are we sure we want software to encourage that? (and therefore AI)
- charcircuit 2mo ago
  Coordinating 2 people working within a single linear stack is unnecessary overhead, even harder for humans to manage. It's easier to let them work off of a shared point individually.
jezzamon 2mo ago
You ideally need a directed graph where descendants can have multiple parents (which JJ supports). If you can't, then the linear tree is just as good I think. Say you do change A, add a protocol buffer API definition, then implement the server logic (B) and the front end code (C) so that both depend on A but not each other. That can be in a tree. But now you want to add an integration test (D) that depends on B and C. The tree doesn't help you there, and you were better off making it a linear chain by arbitrarily picking one of B or C to be dependant on the other so that you have a code state with all of A,B and C applied to create D on top of.

DDayMace 2mo ago

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 2mo ago

inspired by https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack?

ln809 2mo ago

Need to fix the darn font, reads like "stocks" here....

bogota 2mo ago

[dead]

sharpvik 2mo ago

[flagged]

hmokiguess 2mo ago

Ah. That's why the pancakes!

miovoid 2mo ago

Why not to make it part of Git project?

_--__--__ 2mo ago
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 2mo ago

RIP Gerrit

SEJeff 2mo ago
I found the single gerrit user, who downvoted me :)

andy_ppp 2mo ago

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 2mo ago
https://searchfox.org/firefox-main/rev/878b64a4c024f657de81fb66a1e7de1aaad9109c/.agents/skills/reorganize-patches-for-review/SKILL.md 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 2mo ago

This is one of the biggest changes to happen on GitHub in many years.

fenestella 2mo ago

[flagged]

ozozozd 2mo ago

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 2mo ago

You can already PR off another PR but ok. I do it all the time. It’s just merging branches.

chill_ai_guy 2mo ago

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 2mo ago

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.

calmbonsai 2mo ago

As if GitHub wasn’t already unreliable enough. Fix. Your. Culture.

sitzkrieg 2mo ago

public alpha apparently. the concept of quality has not been present since years

necovek 2mo ago

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.

nirvdrum 2mo ago
Thanks for mentioning this. It seemed odd to me, too, so I spent some time trying to work it out. As a reviewer, I'm not sure how I'm supposed to assess database or API changes without knowing how they're intended to be used. And deploying them independently seems odd, too, especially if you need to roll it all back. I think in my ideal world there would be a clean history and I could review a PR commit-by-commit. But, you can't just approve a single commit, so there's a tooling problem there. And most CI runs on an entire push rather than individual commits. And increasingly I see devs using git as an offsite backup for whatever change they just made, rather than breaking commits up into logical chunks. In that workflow, squashed merges make the most sense. It's probably flawed, but the mental model I came up with is each stacked PR collapses into what would have been an individual commit in a clean PR, with the advantage of being able to be reviewed separately from the other changes and forced to clear CI. And then the whole stack becomes what would have been a clean PR in the old model. That, I can kinda see the benefit of. But, merging only part of the stack into trunk is the mental hurdle I can't clear; it'd be like merging only some commits from a PR. It kinda reminds me of when projects used CVS. I've really only seen stacked PRs used on projects where history is little more than an audit log. I'm keen to see how this gets employed by open source projects. I think there's a disconnect and it's likely I'm not going to really get it until I see it.

danpalmer 2mo ago

As someone who previously used GitHub a lot, and now works with stacked changelists (PRs) a lot, I'm not sure this really changes much. If there's an expectation that you might merge a whole stack, I think you're aiming for the wrong thing. And it seems like landing the whole stack is the biggest push GitHub are making here. Part of the point is independently reviewable and independently mergable. If you're going to merge in one go then just put everything in one PR and review commit by commit in that PR. The commit by commit review flow used to suck, but since ~2021 it has been fine. I feel like GitHub have built what users (who haven't used a true stacking system) asked for, not what they actually need to change their workflow for the better. A great implementation would be asking hard questions like: what's the role of a single commit? Should PRs be single commit only? What's the real benefit here? How do you encourage smaller units of review (because it doesn't look like this does).

Kinrany 2mo ago
Yeah: they copied what people were building on top of Github as a workaround to not being able to change Github

ankit84 2mo ago

Stacked PRs are not a new GitHub capability. They are an accessibility. Why so hype? The underlying stacked PR workflow is unchanged: 1. Create branch B from branch A. 2. Open PR A against main. 3. Open PR B against branch A. 4. Repeat for additional layers.

zdc1 2mo ago
I've been doing this for years. Maybe adding some UI sugar around it is nice, but it really shouldn't be that much of a big deal...

whichdan 2mo ago

The issue I have with stacked PRs isn't merging, but rather, when I change branch A, and I'm working on branch C, I then need to merge A into B and then B into C just to continue working. Collapsing/merging them at the end is the easy part.

threethirtytwo 2mo ago

Doesn’t this make it harder for an agent to review?

gsnedders 2mo ago

I’d still love a way to be able to rewrite commits at merge time, via Actions or otherwise. The most obvious case is something like adding a Reviewed-By/Signed-off-by trailer based on reviewers, but there’s also a decent number of big projects that want more semantically meaningful commit identifiers (think more revision, in a numeric sense). It seems like making merges async should make it a lot more possible to implement that!

DmitryO 2mo ago

Next.js is buggy shit. Bad example of usage))

bdubaut 2mo ago

Isn't this going to reinforce the long-lived branches anti-pattern? Large changes can be dangerous

Hypnosis6173 2mo ago

I would love to see more interactions from dev side in GH discussions rather than answering on HN. I think not responding anything there pushes the image of github not caring for the community

beaker52 2mo ago

Looking at the way GitHub are selling this “feature”, I feel like some of the engineers who are going to be excited about this feature for “reviewability” reasons are, in particular, those who’ve forgotten that they should be splitting changes into multiple logical commits inside a PR. And instead of that they’re now going to use multiple, single commit branches and stack them because stacked PRs are a “new” “feature”. And the upshot for the LLM providers is that they get to charge for n reviews, instead of one.

eddythompson80 2mo ago
I think plenty of people explained the difference between stacked PRs and individual commits in 1 PR. You’re not wrong, but it’s just a matter of path of least resistance. There is no way to leave a comment on a particular commit in a PR. Also all commits addressing PR feedback get tucked at the bottom of the commit list. Unless you do some crazy git gymnastics and rewrite the PR history and confuse everyone. With stacked PRs you also (as a maintainer or a reviewer) have the option to merge some and not others. Like here are 3 stacked PRs, one for provisioning some AWS or Azure resources that I’ll need, one for implementing the APIs using those resources, and one for updating the UI to use the new APIs. You can then say “let’s get the 2 backend PRs in and hold off on the UI as we’re changing that entire view”. You can’t do that with multiple commits in a PR without asking the person to redo the PR, then you’re back to git-foo. Yes, GitHub could have made the UI allow a “per commit” comments somehow, then allow you to select the set of commits to include in the merge somehow, then write a blog post on how to manage “Address PR comments #1” commits. But the stacked PRs solve all that. Not to mention how people treat commits as their own internal save states. I always enable “squash and merge” option because I think it makes a lot more sense to have 1 commit on main per PR where all the context of the change is either in the commit message or the linked PR. Also LLM providers charge per token. Charging per “work unit” is still not a solved problem. You can’t charge per “review” when your cost is per token. Just like airlines can’t charge “per ticket”, they have to charge differently depending on the destination. Unless you invent some bs arbitrage to lure users and eventually bait and switch on them.
IshKebab 2mo ago
Splitting changes into multiple commits is a much worse experience if you actually have self-contained dependent changes. 1. The whole review interface isn't set up for reviewing individual commits. 2. You can't merge changes progressively. 3. CI doesn't run on each commit. 4. If you have linear history (good idea IMO) you'll lose your nice commit history when you merge it. This is much better.

sarthak-ag 2mo ago

If your workflow is rebase heavy, I strongly recommend ignoring this github feature and using jj instead. I have written about my experience here: https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/ https://sarthakag.bearblog.dev/from-git-to-jj-jujutsu/

ivolimmen 2mo ago

I personally see no benefit using this. For large changes I often completely work locally until it's done. I commit everything logically and when everything is done I push and make one PR. The commits are not fully done as they work towards the main goal of the PR. If the team argues before the start of the feature that the individual commits are needed we split the ticket. This stacking sounds a lot like shit you need for shit made by LLM's

eddythompson80 2mo ago
The stacked PR pattern long predates LLMs. Yes LLMs make them more common and frequently steer you in that direction. But it’s by no means a new “LLM” thing. In the scenario you described of your team splitting the tickets, this gives you a UI to manage the PRs of the multiple tickets so you are no longer blocked on merging PR#1 before you can proceed to PR#2. Yes you might have to deal with conflicts, but you would have had to deal with that regardless.

grugdev42 2mo ago

I don't want this. It's too complicated. Plus it's vendor lock in. Give it time. Soon you'll only be able to push using Github's CLI.

Shish2k 2mo ago
Other platforms have been doing it this way for over a decade, and I've found stacked diffs (with Phabricator and Gerrit at least, not tried the GH version yet) to massively simplify my workflow o_O

fatwang2 2mo ago

Nice. The pain for me was never creating the stack, it was keeping reviews and restacks inside Github.

ben8bit 2mo ago

Honestly, I didn't even know this was a problem that needed to be solved.

m11a 2mo ago

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.

deleted 2mo ago
[deleted]
steveklabnik 2mo ago
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.
- steveklabnik 2mo ago
  I can't add on to my comment because it's been too long, but a great thread on how much work this is: https://x.com/sameenkarim/status/2083237928092721646 https://x.com/sameenkarim/status/2083237928092721646

slaye 2mo ago

Is this open to regular users of a organization or only organization owners?

feiz45607 2mo ago

[flagged]

dysoco 2mo ago

Can someone explain to me what is the difference between whatever they added new and creating several PRs and "stacking" them by pointing one branch to another via the Github UI? I've always done that. Is it just a nice UI on top of that? Sure merging with one single button is nice but I rarely do that, if I'm stacking PRs it's because I probably want to merge gradually.

jollyllama 2mo ago
It's for people who don't understand long lived branches.
jeltz 2mo ago
Maybe it matters if you do not have the right to push to the main repo but still want both your PRs to live there. Is there a way to do that without stacked PRs?

skipants 2mo ago

This was the feature I wanted the most on Github... until I started using jj. I know that jj isn't for everyone, but for me it's been trivial to see the state of and update all the stacks of branches I have on the go. Not that I don't welcome this feature; I just think I don't need it anymore.

Shish2k 2mo ago
I am confused - I love JJ and stacked diffs with Gerrit and Phabricator, but trying to port that same "each commit gets reviewed individually, and things don't break when a half-reviewed stack gets rebased" workflow to GitHub has been a nightmare, how does JJ help?

pluc 2mo ago

You need some pretty big balls to deliver features when everyone is screaming about your availability

RomanPushkin 2mo ago

bye, graphite

RohoSwagger 2mo ago

dont know why you would use github stacked prs when you can just use ez-stack which has native worktree support and much more extensive functionality, also uses the stacked pr api https://github.com/rohoswagger/ez-stack https://github.com/rohoswagger/ez-stack

dml2135 2mo ago

I didn't see the appeal of bespoke PR stacking tools when it was the headline feature of Graphite, and I still don't see it now. Stacking PRs is useful, but I haven't encountered issues with the ergonomics of just using normal git operations to do it. My stacking workflow is roughly: - Open the first PR from `branch-1` against `main` - While waiting for a review on that first PR, if I need to build on subsequent work in `branch-1`, I'll `git checkout -b branch-2`, and open a draft PR against `branch-1` - If the open review requires me to make changes to make changes to `branch-1`, I'll `git merge branch-1` on `branch-2` to pull them up the stack - After `branch-1` is merged, my draft PR for `branch-2` will automatically update to being opened against `main` - Repeat as necessary depending on how much stacking is requires and how far ahead I get against my reviewers I don't find any of this all that difficult or cumbersome. Is there something that this feature offers, that I'm missing out on?

lukaszkorecki 2mo ago
That's how I worked but it gets tedious for reviewers because there's no easy way to navigate the stack. In the end, I vibe coded an internal PR stacker which stores stack data using `git notes` (allowing multiple people to work in a stack) and updates PR description with stack navigation. It uses merge, rather than rebase because history is not that important (final code is).

rbanffy 2mo ago

I used something similar to this while working for Canonical and I found the idea confusing, the tooling (2014, IIRC) brittle, and the experience overall frustrating. I would never encourage that as a solution to any problem. The most important thing about tooling is to keep it conceptually simple. The fewer moving parts you need to pay attention to, the more brain cells you can devote to solving your problem.

othmanosx 2mo ago

I've been using it for a while and I've actually shipped stacked PRs with github. we usually try to chunk the work so that we don't get in a situation were we have to open PRs with more 1k+ LOC, and we try to plan chunks of max 500 LOC, but I do find myself getting in this situation when the planned work turns out to be more than I anticipated like refactoring or edge cases or review feedback... etc. but that's where stacked PRs come in, I found that they could be useful in this situation to split an unexpectedly large PR into a few smaller ones that are chunkable, individually shippable, and easy to review. but that's where the good stuff ends IMO, stacked PRs just make a bad situation slightly better, and I think we shouldn't get into this situation in the first place. I know that can be impossible sometimes, but I already built my own solution for fix this problem. even though it's good to have, Github's UI doesn't help it, Github already sucks in terms of the review experience in a pull request and the implementation of the stacked PRs leaves a lot to be desired. thankfully, I was working on my own solution for this problem and I already integrated a better stacked PRs implementation compared to github, and I'm pretty happy with it. Pyor (pyor.review), I built it myself, sits on top of github, syncs everything with it, and gives me the benefit of having a better UI and code review experience.

mafo 2mo ago

I'm,in,already,now,live,on,github

mafo 2mo ago

'm,in,already,now,live,on,github

mafo 2mo ago

Show,job,sumit