Squashing and merging a stack is stuck

[mlaccetti]

Before:

After:

I've been stuck looking at these spinners for hours. Nothing is merging. I've cancelled and retried a few times; no luck.

[ace22b]

Same issue with rebase for me.

[andykenward]

Are signed commits required on your repos? I'm having the same issue.

[yannickgloster]

Running into the same issue in our repo as well

[borfast]

My repo does not require signed commits (it's the single one in the org like this, I believe).

The one outstanding thing I can think of is that the stack is based off a commit that is no longer the tip of main, and I'm trying to rebase + merge the stack without updating it first (because I don't want the approvals I have to be dismissed).

[nemith]

I've had the same problem. My repo doesn't require signed commits.

[yannickgloster]

Getting a new error on this now when I go to merge, with no explanation on why it's not mergable

[wolszews]

Getting a new error on this now when I go to merge, with no explanation on why it's not mergable

Same here. First day trying to use GH Stacked PRs and everything works fine but merge'ing (Squash and merge stack)

[MelDommer]

Getting a new error on this now when I go to merge, with no explanation on why it's not mergable

@yannickgloster @wolszews

If you have "require approval of the most recent reviewable push" setting on, this will always happen.

I turned that off then merging the entire stack worked.

[borfast]

If you have "require approval of the most recent reviewable push" setting on, this will always happen.

I turned that off then merging the entire stack worked.

But that defeats one of the purposes (the main one?) of this stacking feature. If we still have to do the reapproval dance after every merge-and-rebase, then we don't really need a stacked PRs feature because we can just continue doing that manually, right?

[MelDommer]

I'm just saying that if you want to be able to merge multiple from a stack, you have to turn that setting off.
When you merge one in, the other HAS to rebase onto the latest. This must trigger that setting because it is now considered a new reviewable push. I'm not saying it is right. Ideally, it would detect that this is a stack merge happening and bypass it. 🤷

I'm just spreading the message. I was getting the same errors trying to merge a stack. Turned that setting off, and it worked fine. Of course I turned it right back on 🤣

[FrkAk]

Same problem, we have stack with everything ready, but both squash or merge does not work.

[sassomedia]

Luckily, for us it didn't get stuck when trying to merge the stack. However, it only merged the first (bottom) PR, then returned to "Ready" status for the other PRs.

Since only one PR got merged, the "Rebase Stack" button became available again, but upon trying to rebase, it reported conflicts. Yet, there were no conflicts, as a local gh stack sync rebased fine without issues. After the sync, the PRs were ready to merge again, but seemingly only one at a time. - Stack mergeing does not seem to work at this time.

[sassomedia]

I think I know what the issue is, at least in our repo setup. We squash our PRs when merging them into the main branch.

What GitHub tries to do is merge-squash every PR in sequence, from the first to the last. The first one is always successful, but then it fails on the second one, because now there are conflicts. That sort of makes sense, because the history changed. However, a local rebase doesn't actually have conflicts as it properly rebases from front to back.

I believe all they would need to do for a stack to successfully merge-squash is to start from the last branch. It contains all changes from the other branches. So only the last branch needs to be merge-squashed, and all the other ones could be automatically closed.

This is the workaround I currently do once a stack is fully approved:

1. Locally check out a new branch (not part of the stack) git checkout -b combined-stack
2. Squash all commits from the top stack branch into the new branch git merge --squash <TOP_MOST_BRANCH_NAME>
3. Commit, push and create a new PR with the new branch that now contains all changes of the stack
4. Merge(-squash) the PR into main
5. Close the stack manually (close and delete each branch)

[phillip-haydon]

We don’t use squash. We have the default merge commit. It’s still fucked for us.

[skarim]

x-posting from #256

Hey all, thanks for the reports. We've identified a bug where approvals are not being appropriately evaluated when merging a stack of multiple PRs. We're actively investigating and will update when we've released a fix.

In the meantime, you can get around this by merging one PR at a time. I know it's not ideal, but hopefully that will unblock your workflows in the short-term. Appreciate your patience!

[nemith]

Also I reported this 22 days ago.

#168

[borfast]

@nemith I've been doing the same, praising stacked changes for years, have pestered people to join the preview, and now they're all looking at me and going "is this what you've been selling us as the greatest thing ever? 😒" - not great for my reputation 😅 But also not great because people will think this is the stacked changes experience, they won't want to touch it, and we all end up losing.

[phillip-haydon]

@borfast that's not true as of yesterday, see https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/

I stand corrected. Thank you @alexharri .

You’re wrong. And even if it was closed beta it should be in a better state than it is.

@phillip-haydon I would disagree on the closed beta, since its whole purpose is to start getting feedback while still being able to make big mistakes. Public beta is a different story, and there I would agree that this is definitely not at a level for a public preview. The feature is pretty much broken and not useful, which is not expected of a preview - if it doesn't work, what are people going to preview? 🙂

I’m pretty angry because the people at github obviously have checked out and don’t care about what they deliver.

https://x.com/cassidoo/status/2083210982847910127?s=46&t=gSe7f3HqlOJ1WkvKbrmlnQ

Look at this.

Okay so now that we shipped stacked PRs, what's the next biggest request you have for GitHub to take on?

What the hell is going on inside GitHub. Ship stuff and move on? They don’t care about the customer experience at all.

[TRStarr]

merging one PR at a time

This has caused my stack of 11 PRs to rebase, require re-approval and triggered new builds... now waiting for each build to complete and others to approve.

I am very disappointed in stack PRs considering the amount of hype GitHub have made about this

[WalterWong-Wise]

Hello @skarim, just wondering if there is any update on the fix? Thank you. 🙇‍♂️

[juliosampaio]

I’m seeing the same problem here :/ Since the public preview started, it hasn’t been working properly.

[nemith]

pretty sure it never worked (branch protection rules around dismissing reviews + stacking). There has been no indication of timeframe to fix either.

The problem is turning off the the protection rules is a non-starter for a lot of companies.

[jothompson-prismhr]

I know I tested it and it worked before I rolled it out for our team to use. Then the next one I tried had issues. So I'm wondering if it has to do with a change to our build to use an Azure DevOps pipeline to doing it in Github Actions.

[phillip-haydon]

I know I tested it and it worked before I rolled it out for our team to use. Then the next one I tried had issues. So I'm wondering if it has to do with a change to our build to use an Azure DevOps pipeline to doing it in Github Actions.

Nothing to do with your use. It’s an issue with incompetent developers at GitHub.

[GuillermoGaete]

Same issue here! Will you fix this in the short term?

[michal-samluk]

I have the same issue.

[RaniAgus]

Same here. And merging one by one doesn't work because it reruns the CI every time and drops PR approvals, so it's not a valid workaround.

[rcarrion2]

I have the same problem. It's a shame.

[joshuastone]

I have this issue as well, which completely eliminates one of the main benefits of stacked PRs as they're unable to merge together atomically via a single merge group in the merge queue.

My basic stacked PR setup

• Two PRs: A and B
• A branches off main, B branches off A (main -> A -> B)
• Linear stack with only one commit each
• Both PRs MERGEABLE outside the queue
• Full stack is capable of fast-forwarding into main with zero conflicts (tested locally)

Observed behavior

• Click the "Enqueue stack (2)" button on PR B → PR B immediately reports conflicts while in the merge queue
• Dequeue the stack → conflict on PR B immediately disappears when outside the queue
• If I don't dequeue the stack, PR A merges and PR B gets ejected

Settings

• require_last_push_approval: false
• required_approving_review_count: 0
• allowed_merge_methods: ["rebase"]

Note that unlike others, my repository doesn't even require approvals or signed commits.

[duartealexf]

same issue here: stuck on merging status when merging via ui button. When I run gh stack merge 1796 --merge --merge-method merge, selecting all of them I get this message:

merge failed: protected branch 'qa' check failed:
  At least 1 approving review is required by reviewers with write access.
Stack merges are atomic, so nothing was merged.

EDIT: it was a stack of 8 PRs... I merged them all by just merging the stack tip and closing the other 7 PRs.

[tucomel]

Same here 😞

[yoo0926]

In my case, this turned out to be a branch protection setting.

Stack of 2 PRs, both approved by a write-access member, all checks green. The web UI sat on Merging stack… indefinitely with no error, on both rebase and merge-commit. gh pr view reported mergeStateStatus: CLEAN, reviewDecision: APPROVED for both PRs.

gh stack merge surfaced the actual reason immediately:

merge failed: protected branch 'main' check failed:
  At least 1 approving review is required by reviewers with write access.
Stack merges are atomic, so nothing was merged.

Disabling Dismiss stale pull request approvals when new commits are pushed on main made the identical stack merge on the first attempt.

My guess is that the automatic restack of the upper PR after the lower one lands rewrites its head SHA, which trips dismiss_stale_reviews mid-merge and fails the protection check — though I haven't observed that directly.

Two asks: (1) surface this error in the web UI instead of an endless spinner, and (2) consider not treating GitHub's own restack as a stale-making push. When the diff is unchanged and the author pushed nothing, dropping the approval defeats the point of merging a stack in one operation.

[rajatmoengage]

Is there any update on this bug?

[TRStarr]

@imanmahjoubi its been 2 weeks since your last post; could you please provide an update? even if the update is there is no update... feels like this has been forgotten about...

[Eitz]

Guys, please add some observability to this, it has been broken since day one for countless people on the most generic of things.

Also it being unable to leave the merging state and failing to report that something is/was wrong is a really sad state of affairs.

[cesarviana]

Any updates, please? My team is stopping using this feature (which seemed nice at first) because the last step is failing...

[phillip-haydon]

I doubt they will update or fix this. The good developers all left github long ago. They are busy thinking of what new slop they can create rather than fixing what they couldn’t get working.

[mafsays]

yeah temporarily disabling "Dismiss stale pull request approvals when new commits are pushed" sorted this out for me, but this is literally the reason i embraced this feature (and bigged it up to my colleagues) - as it stands it's all a bit pointless 🤷

[SteppingRazor]

I've personally given up waiting for this. The last update was over a month ago and the issue has been known for at least three months now. I hope I am wrong but I don't see the fix coming any time soon, if ever.

[vuon9]

We were too excited to tell all our colleagues that GH just released a cool feature. GH employees did that as well by selling it on social networks. Then we found the feature too broken, and we simply couldn't know why or when they would fix it. I'm too disappointed about it; I know I have expected too much from the GH team.

[lakardion]

They released in preview to get feedback, and they're ignoring it.
I think this is the most valuable thing about stacked prs, without it we just have a nice UI but still the same manual hassle of before

[valters]

Forgot the minor thing of supporting signed commits. Oh well.

[benoror]

Getting similar issues, on CLI I get:

❯ gh stack merge 2251 --yes --squash

Merging #2196, #2197, #2208, #2210, #2211, #2232 into main via squash...
✗ merge failed: protected branch 'main' check failed:
  At least 2 approving reviews are required by reviewers with write access.
Stack merges are atomic, so nothing was merged.

Even though all PRs are ✅ green already and meet the requirements.

[MattCheetham]

Running into this issue today too, my first time using Stacked PRs. Now wondering why I wasted time trying it out now that I have to go back and merge and rebase everything one at a time anyway. Sigh.

[VincentBernet]

I have the same issue, it has been in merging state for hours :

[brettdh]

More buggy behavior - in a stack of 4 PRs, I just merged PR 1, and during the rebase of PR 2, it got a bunch of unnecessary CODEOWNERS groups assigned - presumably because the PR 2 branch briefly was based on master before the auto-rebase happened, and because we squash-merge PRs in this repo, PR 2's branch briefly looked like it contained all of PR 1.

This is precisely the sort of thing that was a pain with stacking PRs manually before this feature, and the things I'm looking to the stacked PRs feature to solve. I'm not just looking for a nice UI to navigate between stacked PRs. I'll say again that this feature was not ready for preview, but given that it's here, some communication and direct engagement with the feedback we're providing would be greatly appreciated.