5 ms·

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

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
RyJones 2mo ago
This is the feature I’ve missed most from Gerrit. Thank you
joenot443 2mo ago
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.
lobofta 2mo ago
I needed this feature! Thank you
dogleash 2mo ago
> Also happy to answer questions about the design decisions we made. Why did you choose extra pull requests as the division of work instead of building out a decent UI for reviewing/applying/reworking at the commit level? I assume there's some extra insight that made you ignore the mailing list "series of patches" workflow that inspired this whole thing and go with "series of series of patches" instead.
hedgehog 2mo ago
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.
miovoid 2mo ago
Why not to make it part of Git project? Such fragmentation adds complexity and vendor locking.
- saghm 2mo ago
  Presumably because "vendor locking" is pretty much their entire business model
- CBLT 2mo ago
  I'm trying to understand what you mean, because it's not obvious to me at all. If you read LKML you'll see stacked PRs has been the norm for years. I'm assuming you want the `gh stack` porcelain into the git cli? We'd first need to add PRs as a porcelain to the git cli for it to make any sense, right?
  - Too 2mo ago
    Gerrit manages stacked changes with standard git tooling, except for the tiny change-id hook. Similar stable change identifier is also what enables Jujutsu to do its magic. Standardizing around something like this would be greatly beneficial, instead a ”gh” CLI is now needed to push a commit.
    - Shish2k 2mo ago
      JJ, Gerrit, codebutler, and I think a couple of others have all basically agreed upon a syntax for change IDs and they are converging their prior ad-hoc formats into one; but last time I checked, the request to the upstream git team of "please don't silently drop the change-id header during rebase or amend" was met with bike-shedding about all the other hypothetical benefits that alternative formats could hypothetically provide, so universal support for the header as used in practice today is still missing D: (I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)
      - steveklabnik 2mo ago
        This is roughly the current state of things as I know about it, that said I haven't read a lot of git's mailing list lately so it's possible that there have been some other developments.
mattmatheson 2mo ago
Congrats Sameen and the rest of the team! Excited to see stacks make it into GitHub. We worked with Sameen over the last month to add support for GitHub stacks into our mergequeue, and I'm excited to announce support for it today: https://trunk.io/blog/trunk-merge-queue-now-supports-github-stacked-pull-requests https://trunk.io/blog/trunk-merge-queue-now-supports-github-...
sunshowers 2mo ago
I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs? The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge workflow, which is simply worse than an amend + rebase workflow. Basically every other review system in existence -- Gerrit, Phabricator, what Google and Meta have internally, the LKML -- works around stacks where people amend and rebase their commits when changing them. All of these have some notion of a "diff", with "versions" that are each tracked separately, and the ability in the review tool to do diffs between those versions. My hope with stacked PRs was that for once GitHub would use this as an opportunity to modernize its review system and bring it in line with all of these other ones. But sadly that just doesn't seem like it's on the cards.
- huflungdung 2mo ago
  [dead]
- ptx 2mo ago
  Doesn't GitHub do this already? If I force push the PR branch, the PR shows a message about this with a link to diff it against the previous version.
  - sunshowers 2mo ago
    That is nowhere close to the experience Gerrit and Phabricator have, where you can diff two arbitrary versions in history. Comments on previous versions also get lost along the way.
  - sefrost 2mo ago
    Personally I find this feature works 50% of the time, and I don’t understand why.
  - Groxx 2mo ago
    Mostly. You can't do "show me this commit in the stack before and after the force push" though iirc. And you can't comment on the derived diff, even though that's what you'll be reading during re-review to see what changed. GitHub constantly feels like features get requested with a one-sentence description, and then people who have never used any other major code review systems go build it without any further assistance or feedback, and eventually it just escapes containment and nobody tells the authors that there's a gigantic pile of bug feedback threads until almost a year later. Ten things get fixed, then another feature breaks out and focus shifts.
MBCook 2mo ago
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.
- fphilipe 2mo ago
  I was using my usual stacked PR approach without the CLI and it detected the stack. So I think the CLI just does the heavy lifting for you (although I prefer to stick to vanilla git rather than learning a new tool).
  - MBCook 2mo ago
    Oh good! I have had a chance to try it.
- carderne 2mo ago
  What do you gain by having multiple repos?
DreadY2K 2mo ago
How long until support gets added for repos with merge queues? I'd love to use this at $WORK and so would my coworkers, but we can't turn off the merge queue so we can't use stacked PRs until they can mix.

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

RyJones 2mo ago

This is the feature I’ve missed most from Gerrit. Thank you

joenot443 2mo ago

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.

lobofta 2mo ago

I needed this feature! Thank you

dogleash 2mo ago

> Also happy to answer questions about the design decisions we made. Why did you choose extra pull requests as the division of work instead of building out a decent UI for reviewing/applying/reworking at the commit level? I assume there's some extra insight that made you ignore the mailing list "series of patches" workflow that inspired this whole thing and go with "series of series of patches" instead.

hedgehog 2mo ago

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.

miovoid 2mo ago

Why not to make it part of Git project? Such fragmentation adds complexity and vendor locking.

saghm 2mo ago
Presumably because "vendor locking" is pretty much their entire business model
CBLT 2mo ago
I'm trying to understand what you mean, because it's not obvious to me at all. If you read LKML you'll see stacked PRs has been the norm for years. I'm assuming you want the `gh stack` porcelain into the git cli? We'd first need to add PRs as a porcelain to the git cli for it to make any sense, right?
- Too 2mo ago
  Gerrit manages stacked changes with standard git tooling, except for the tiny change-id hook. Similar stable change identifier is also what enables Jujutsu to do its magic. Standardizing around something like this would be greatly beneficial, instead a ”gh” CLI is now needed to push a commit.
  - Shish2k 2mo ago
    JJ, Gerrit, codebutler, and I think a couple of others have all basically agreed upon a syntax for change IDs and they are converging their prior ad-hoc formats into one; but last time I checked, the request to the upstream git team of "please don't silently drop the change-id header during rebase or amend" was met with bike-shedding about all the other hypothetical benefits that alternative formats could hypothetically provide, so universal support for the header as used in practice today is still missing D: (I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)
    - steveklabnik 2mo ago
      This is roughly the current state of things as I know about it, that said I haven't read a lot of git's mailing list lately so it's possible that there have been some other developments.

mattmatheson 2mo ago

Congrats Sameen and the rest of the team! Excited to see stacks make it into GitHub. We worked with Sameen over the last month to add support for GitHub stacks into our mergequeue, and I'm excited to announce support for it today: https://trunk.io/blog/trunk-merge-queue-now-supports-github-stacked-pull-requests https://trunk.io/blog/trunk-merge-queue-now-supports-github-...

sunshowers 2mo ago

I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs? The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge workflow, which is simply worse than an amend + rebase workflow. Basically every other review system in existence -- Gerrit, Phabricator, what Google and Meta have internally, the LKML -- works around stacks where people amend and rebase their commits when changing them. All of these have some notion of a "diff", with "versions" that are each tracked separately, and the ability in the review tool to do diffs between those versions. My hope with stacked PRs was that for once GitHub would use this as an opportunity to modernize its review system and bring it in line with all of these other ones. But sadly that just doesn't seem like it's on the cards.

huflungdung 2mo ago
[dead]
ptx 2mo ago
Doesn't GitHub do this already? If I force push the PR branch, the PR shows a message about this with a link to diff it against the previous version.
- sunshowers 2mo ago
  That is nowhere close to the experience Gerrit and Phabricator have, where you can diff two arbitrary versions in history. Comments on previous versions also get lost along the way.
- sefrost 2mo ago
  Personally I find this feature works 50% of the time, and I don’t understand why.
- Groxx 2mo ago
  Mostly. You can't do "show me this commit in the stack before and after the force push" though iirc. And you can't comment on the derived diff, even though that's what you'll be reading during re-review to see what changed. GitHub constantly feels like features get requested with a one-sentence description, and then people who have never used any other major code review systems go build it without any further assistance or feedback, and eventually it just escapes containment and nobody tells the authors that there's a gigantic pile of bug feedback threads until almost a year later. Ten things get fixed, then another feature breaks out and focus shifts.

MBCook 2mo ago

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.

fphilipe 2mo ago
I was using my usual stacked PR approach without the CLI and it detected the stack. So I think the CLI just does the heavy lifting for you (although I prefer to stick to vanilla git rather than learning a new tool).
- MBCook 2mo ago
  Oh good! I have had a chance to try it.
carderne 2mo ago
What do you gain by having multiple repos?

DreadY2K 2mo ago

How long until support gets added for repos with merge queues? I'd love to use this at $WORK and so would my coworkers, but we can't turn off the merge queue so we can't use stacked PRs until they can mix.