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]

Serious it is unusable as it and shocked to see it in public preview when the cor functionally doesn't even work.

If I try to use it I end up berating my coworkers with request to restamp already reviewed diffs.

The worst thing is I have been talking up stacked doffs and this announcement to others for months and now my reputation is as good as GitHub's when it comes to this feature.

Disappointed is an understatement and continues to show how much GitHub has fallen.

[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

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

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

[TRStarr]

I have found a life hack around this, create a new PR from based of the last PR of the stack pointing to the target branch of the first PR of the stack i.e. feature/11 -> master

With merge commit turned on (not squash) it will allow you to merge all PRs in one go, with only needing the new PR to pass checks.

I know we all joke about test in prod but GitHub made it a reality!

[tekumara]

The workaround for now seems to be merging each PR one by one.

I've written https://github.com/tekumara/gh-stack-merge to automate this. It merges the stack one by one from the bottom up, waiting for checks to be ready on each PR before merging.

[rcarrion2]

I confirm, I'm doing the same.

[nemith]

I assume you don't have branch protection rules that dismiss changes when then base changes? This is forced by my org.

[brettdh]

Same. I still like the stack's automatic rebase, and sometimes bottom-up merge happens anyway when earlier PRs are approved earlier, but it can't be automated when approvals get reset on rebase.

When things like this are still being "worked on":

In addition, we're working on an update to retain the approvals on upstack PRs after a partial stack merge.

the feature's simply not done.

[gps035]

I ran into this on my first stacked PR, and now I'm going back to not using them.

This should have been a total showstopper that blocked a move to public preview.

Could you please do another release announcement when this feature is usable?

[Alvov1]

Same issue for me: first PR stack, 3 PRs. Stuck forever during squash+merge

[renancaraujo]

This is happening intermittently now. Sometimes it goes, sometimes it doesn't.

[patrickatg]

Never works for me.

[patrickatg]

"Merging" and the spinner icon is just loading and nothing happens.

[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 🤷