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!

what if you stack a draft PR on top of a regular one?

If you thought git was complex, wait until you get your 5 deep stacked PR from that nice coworker! Jokes aside this is really an anti-feature. Now coworkers can blow off your PR for much longer.

hahahah yeah my company had sooooo many issues with this stuff and merge queue lately

You’re surprised? Really? I’m more surprised that they pushed a major change and the site is still up.

> 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.

By the way could there be a way to disable that when doing integrations externally? It seems to be quite costly (which makes sense), and the pull/ refs kinda bloat the reflist.

I’m sure that external integration is not exactly beloved internally but there’s really just a small handful of big annoyances which would make it so much nicer and more comfortable.

We just today ran into a bug where if the branch a stacked PR points to is deleted, it can just stay stuck in "merging" without any additional feedback. I directly looked at the GH status page, because who knows, maybe the PR subsystem has a partial outage again, but no, it was just a bug in the stacked PR feature.

the whole industry has become completely “ready, fire, aim” since 2021

Can you make sure there is good API support for stacks?

We use a custom merge queue and we want it to be able to land multiple PRs from a stack at once as separate PRs. Last I checked you had to land a single PR, rebase the stack, land the next and so on. This is very expensive in CI time (and wall clock time), vs simply testing part or all of a stack in parallel then declaring those merged. In essence a robot needs the ability to say “squash merge these 3 stacked PRs”, after the queue does its thing.

I needed this feature! Thank you

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

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.

> 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.

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.

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.

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

> What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit?

Even if the reviewer does the review commit-by-commit, all the comments and discussions will be on the same PR leading to multiple ongoing conversations about different topics that would be split if the PR are stacked. Also, all the new commits addressing the comments with spoil this commit-by-commit design, as the previous commits will be outdated and the new changes will be on top of those. I think it's beneficial for new changes to be a separate commit and not rewriting history, to not force the reviewers to re-read everything but just the latest changes.

> What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit?

What I can see is that you can easily append commits to e.g. the first PR in a stack, which would insert them into the middle of sequence of commits.

This will require rebasing and fixing the subsequent PRs in a stack the same way you'd need to rebase and fix the subsequent commits in a mega-PR. But it makes the right thing easy (keeping all the commits to the foundation of the change together) rather than makin the wrong thing easy (appending fixup commits across the entire change in a random order so that the actual foundational change is lost).

Keeping all the foundational commits together also keeps all the discussion over the foundational change together.

You could argue that you'd want to only do the foundational PR and stop, but doing the whole stack of PRs gives the reviewers more information about where you're going, and allows work to continue asynchronously.

I would say that it makes it easier to design a PR and then go back and update that PR as things evolve. For instance, you might decide you need one table so your first PR in the stack adds that table. But then you finish up with 2 or 3 more PRs and you get reviewed and you and your colleagues decide to add a 2nd table. Now you get to go back to that first PR, add the 2nd table and then you get to cleanly review that 2nd table. Then each PR in the stack also gets a clean small addition to handle the table, that can be reviewed in its own context with smaller diffs.

So the idea is you can much more cleanly isolate changes for large features.

GitHub has been especially bad.

Ultimately they have become a monopoly so it is kind of expected.

Thanks, definitely sounds like a bug. Will look into this.

With stacking you can continue working on a longer change while creating reviewable diffs. Merged diffs can be rebased on your HEAD. For teams that support stacked diffs you don't usually even need to manage branches and work directly off trunk and rebase changes as they come in

I don't have experience with the stacked PR workflow and often find myself asking the same questions you are.

As far as I can tell, the biggest benefit of stacked PRs over just making a coherent series of commits, is that it might make it easier to start work on your second PR before you merge the first one?

With human-in-the-loop coding, that sounds like it could lead to a lot of wasted work if the first PR gets substantial feedback. But with agentic coding, I can imagine how it might be desirable to keep the agent chugging while the first PR is under review.

Interested in learning more about it and generally agree that AI is stressing the current review paradigms a lot of us are accustomed to.

Yes that was one of our top priorities. For one, there's a fully public API for all stack operations. So if you don't want to use the `gh stack` CLI, you can build your own: https://docs.github.com/en/rest/pulls/stacks

For merging, we have an API but had to move it to a new async method: https://github.github.io/gh-stack/reference/merge-api/

The legacy API was fully synchronous, and since stacks of multiple PRs can often take more than 10s (our global timeout), we had to move to async.

We've had some folks already use this to integrate stacks into their merge queues. The great part is you can land multiple PRs in one atomic operation, and then there's one push to main with all your commits from multiple PRs. So instead of having to rerun the build/deploy for each, it can trigger for the last commit that contains all of the changes.

> 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.

It’s the “well-curated” part. Many folks treat commits like video game save points, and find providing any kind of message burdensome (e.g. “fix bug”, “do work”). This alone is fine, but then they can’t be bothered to go back and clean it up with `git rebase -i`, so you end up with a mountain of trash in your git log if you don’t turn on mandatory squash and merge. For these folks, the PR becomes the commit. Stacked PRs is revolutionary because it’s as though these developers can finally have multiple commits which comprise a change.

You can’t merge one commit at a time in a PR. In a stack, if the first 4 parts of a feature are good to go and there’s a problem with the 5th, the whole thing doesn’t need to be blocked.

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.

I've had that same "what's the point" thought every time I've read about stacked PRs, but recently had an (obvious) epiphany. The benefit is you get CI for each commit! I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need.

This is definitely connected to AI. High code volume, bigger PRs.

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.

I feel it's more of a limitation of the GitHub UI. It is much easier to group together reviews and comments by PR than it is by commits.

For a moment, I thought it was a reddit-style account birthday badge

Currently same repo only, fork support coming soon.

Exactly, I feel the same way, and was surprised to see so few people pointing this out. Forest vs desert I guess.

That sounds difficult for a human to manage, are we sure we want software to encourage that? (and therefore AI)

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

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.

I don't mind rebasing, so that's not really an issue.

The problem I sometimes have is when I queue up 4 or 5 PRs in the afternoon and expect someone to take a look in the morning.

The diff of A into master looks OK, but then the diff of B looks like AB, and the diff of C looks like ABC - each PR has changes that will have already been merged once earlier PRs have been accepted.

My way around it was to raise E as a PR into D, raise D as a PR into C, etc. Then once approved, I change their destinations back to master for the actual merges.

It really confuses reviewers though, even though it's meant to make it so they only see the appropriate changes.

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.

Yes: https://github.com/orgs/community/discussions/203497

GitHub has about as much of a shot of doing that as I do of fixing my allergies by updating the base human genome.

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.

> 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)

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 :)

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.

> 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.

I also don't get it.

> With stacks, you can independently review and check each pull request, then merge everything together in one click.

Consider:

"With pull requests, you can independently review and check each commit inside the pull request, and then merge the entire pull request in one click."

Pull requests are stacked commits. This does not have to recurse; you don't need stacked pull requests, not to mention stacked pull request stacks.

A commit can already contain changes to multiple files. In many cases, even a complex change can be just one commit. A sequence of multiple commits handles all the remaining cases.

Stacked PRs sound like a use case for someone who never wants a PR to be a container for multiple commits, such that if a unit of work is best done as three commits, they want them in separate PRs. Oh, but now they are not related together, the way a stack of commits is related under one PR, so we need a meta-PR to contain PRs or something.

This could be a consequence of commits being sort of second class citizens in the GitHub UI compared to PRs. If you want a commit to be treated as PR, on the same level, you must create a PR with nothing but that commit. So then, what would have been a single PR with four commits that you could merge with one click is now four PRs. Which you want to be able to merge them with one click.

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.

> (e.g. “fix bug”, “do work”)

or "skjdnfks" and "fsdfs" commits.

There is real value in having all the messy commit history, especially now with AI, but you do need some kind of description on them that indicates what they are.

One use I have got from it is asking an agent to go through the git history and categories the mistakes/bugs, then turn the common ones into CI checks or AGENTS.md rules.

A well curated history just hides a lot of valuable info.

I wonder if they could have added the ability to take only certain commits from a PR though?

It kinda seems like they're duplicating the "unit of change" arbitrarily, rather than just fixing the way a PR works.

I think the reason I find that a bit icky is it seems like it's diverging GitHub from the underlying git tool, which I trust a lot more.

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.

I don't get it, we already have CI for each commit, at least at our workplace, enforced.

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.

How does git-spice compare to git-town?

> I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need.

Can't you run your CI locally? I know it's not feasible for some codebase, but at least the linting, formatting, unit tests, some integration tests should be able to be done locally.

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.

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.

I was so happy when I saw that! There is joy and silliness left in GitHub! Thank you!

I liked it. It’s nice to have little fleeting moments of what I call “Classic Web” feel.

I certainly don't want to see that in a one commit. A PR has one more more commits, though.

The commits in a PR are already a stack of patches, and so PRs are already "stacked" as they are.

If feature X depends on the refactoring (cannot be rebased on the un-refactored upstream), it's part of the change; you can't just merge the feature and not the refactoring.

If the two are separable that way then, sure, it makes sense to ask for them to be separate PRs.

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

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.

> With pull requests, you can independently review and check each commit inside the pull request, and then merge the entire pull request in one click

Except you can’t really do that on GitHub, the “unit if review” is the PR so reviewing commits is adhoc, inconsistent, and awkward, and tracking their changes as they get fixed up is a pain. “Splatting” that as PRs is not the nicest way to do it green field, but it’s an evolution that makes sense in GitHub’s model.

Good. This change was unexpected and so unprofessional I though my browser was compromised.

I do that too. I do introduce changes in separate PRs. They could be related to the same problem and referenced accordingly.

  and the changes depend on each other so I can't open multiple independent PRs

Why? Is it a technical restriction? Tightly coupled architecture is not the best solution anyway.

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

> That can be easily done with comments. If the PR are orthogonal, they could have been split.

Comments are ad-hoc and don't scale, relying on the author to interpret and adhere to the extent of the reviewers approval.

> 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.

you are free to look up, down, and around the stack; nobody is hiding the code from you. But in many cases this is just unnecessary.

The PRs may be orthogonal but still be dependent. Feature X depends on improvement Y which also needs bugfix Z. You might go and implement X in a branch, tweaking the codebase as you go, but split the branch apart for review. You put X/Y/Z up, but X contains Y and Z, which means you can't request reviews for X without Y and Z merging, or else have a bunch of extra code that gets in the way.

>Can't you run your CI locally?

If you mean automated tests and linters, sure.

Conceptually continuous integration is generally integrating 2+ different lineages of code together which is more common with multiple developers although I suppose it's becoming more relevant with agents creating a bunch of worktrees with different things.

In practice, CI has taken the same path as "DevOps Engineer" ie most people just mean "automated test server"

The opposite of CI is more-or-less merge windows or merge-fest like Linux where everyone mails in their changes and someone manually integrates.

You can't have mac/windows/linux/whatever all locally simultanously.

Not every project requires this, but for those that do, it's impossible.

Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly" than it is when it's on your forge.

They could but they don't belong together. A PR should be about one thing. Refactoring one module for another's sake should be done in another PR. If not for reviewing, for revertability, and future debuggability.

You thought your browser was compromised? Pathetic.

You should give Azure DevOps a try!

Right; so maybe that's the thing to fix.

A refactor and then a feature implemented on that refactor is tightly coupled by definition. It would not make sense to implement the feature and refactor independently, because you’d be wasting time implementing a feature that you would have to refactor again.

My lord people accept a little bit of whimsey in your lives.

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.

Let's say that Z has an error (some assumption that does not hold), and needed to be reverted. How does that impact X's viability? I wouldn't trust any reviews of X after that.

I strongly believe that PR should be compared to the main branch, and not rely on unmerged code. Unless you merge everything together in one go. And in the latter case, everything should be reviewed together.

> Conceptually continuous integration is generally integrating 2+ different lineages of code together

> In practice, CI [often means] "automated test server"

Could you say more? I use "CI" to refer to the automated processes that run tests and (maybe) deploy code as it is merged to some blessed branch. It's what continually integrates the new code into the existing code. What am I missing?

This is literally the point of stacked PRs. You implement the refactor in branch A, then branch B is created on top of that so you can implement your feature. Then you make separate PRs, one for merging branch A into main, and another for merging branch B into A. The GitHub feature just provides a nicer UX when interacting with such PRs by clearly showing dependency and allowing you to merge a stack together.

> You can't have mac/windows/linux/whatever all locally simultanously.

Why can't you? That's what VMs are for. And even then, most cross-platform codebases have an abstraction layer that rarely changes. So even testing on one platform can raise your confidence very high.

> Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly"

Again why? I wouldn't care about the dev's local branch. But what is send to the main repo can be easily scripted to run the CI on every commit. You just send the result back with each commit that fails. They can replicate the same workflow on their local workspace as a pre-push process.

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.

> They don't. But reviewing individual commits in the GitHub UI is hard.

So instead of solving that problem, GitHub developed tooling around a workaround for that problem (targeting a PR at another branch that also has a PR).

Expanding reviews to allow per-commit reviews avoids the need for managing additional branches and all the headache that comes with it.

If the tooling allows rollbacking X, Y and Z as a set, it could make sense ?

I'm also on the "compare to the main branch" camp in general, but will sometimes end up with a set of X,Y,Z branches that have different purposes but all depend on X.

More often than not, the base dependency is a set of constants or additional class/methods that could be released with no impact (no reference in live code) but still need a somewhat lenghty review process. Reverts would be happening on the higher level PRs, which hopefully are independent.

I think the answer is - it depends! This is why we make good money. I don’t think there’s a hard and fast rule here to apply.

Funnily enough the two features that I've missed from phabricator are Stacked Diffs and the per-user opt-in whimsy mode, maybe GitHub can copy the latter next? :D

You can't run MacOS in a VM on non-Mac hardware without violating Apple's EULA.

> But what is send to the main repo can be easily scripted to run the CI on every commit.

Sure, this could work. I didn't say it was impossible, just more difficult. You have to build all of this support on top of the system that already does it for you: have your forge run CI on every commit.

Indeed. But lots of people have never even heard of Gerrit :P.

And the implementation feels very much like it sits in the UI layer, rather than further down the stack.

I'm not trying to claim stacking PRs in this way is the best way (it's not). But it does add an extra affordance for those who want it without burdening those who don't with the need to understand why someone would prefer it.

And there are also plenty of ways that people have been working around GitHub's (and to a lesser extent, git's) lack of tooling for working on changes in this way. I'm sure they have customers clamouring for the feature; whether they'll be happy with what they get remains to be seen.

(Very happy jujutsu user here, my tooling makes it really easy to create stacked commits with a stable identifier that maps really easily to branches and then onwards to running `gh stack`, but what GitHub have delivered is definitely still lacking)