Repository navigation
Stacked PR cannot be merged into a merge-queue branch #268
Description
Repository / PR / stack numbers and the ruleset regex below are fabricated/illustrative; the behavior and error strings are verbatim from a real occurrence. (UI-error screenshot to be attached.)
Summary
The bottom PR of a gh stack (v0.0.8) stack cannot be merged into a merge-queue-protected branch by any path:
- API:
enablePullRequestAutoMergeandenqueuePullRequestboth fail:This pull request is part of a stack and must be merged sequentially using the stack merge API.That API is not in the public GraphQL schema, andgh stackhas nomergecommand. - UI ("Merge when ready" → "Confirm enqueue pull request"): fails with
Repository rule violations found — Commit message must match a given regex pattern. The stack-merge creates aMerge pull request …merge commit despite the queue'srebasemethod, so it violates acommit_message_patternrule that only allowsMerge branch ….
Non-stacked PRs merge through the same queue fine. Only unstacking (gh stack unstack) unblocks the merge.
Working hypothesis: the trigger is a merge-queue branch whose rules reject merge commits. The stack-merge creates a Merge pull request … commit instead of rebasing (as the queue's rebase method would), and that commit fails commit_message_pattern. Observed: the API rejection and the rule violation. Inferred: that the offending commit is a merge commit (a rebase of the PR's compliant commits would not trip the rule).
Environment
gh2.96.0,gh stackv0.0.8- Trunk
mainruleset:merge_queue{merge_method: REBASE},pull_request{allowed_merge_methods:["rebase"]},commit_message_pattern=^((feat|fix|chore|docs|test|refactor): .+|Merge branch .+) - Stack
main ← #101 ← #102; bottom PR#101approved, checks green, up to date withmain.
Repro
- Trunk with a merge queue (rebase) + a
commit_message_patternrule forbiddingMerge pull request …. gh stack init #101 #102→gh stack submit.- Bottom PR green + approved + up to date.
- Merge it via
gh pr merge #101 --auto --rebase, theenqueuePullRequestmutation, or the UI.
Expected
Bottom PR enqueues and merges with the queue's rebase method, like an equivalent non-stacked PR.
Actual
- API:
This pull request is part of a stack and must be merged sequentially using the stack merge API.(UNPROCESSABLE, not enqueued). - UI:
Repository rule violations found — Commit message must match a given regex pattern: ….
Likely cause (working hypothesis)
- Enqueue/auto-merge mutations are blocked for any stacked PR, deferring to a "stack merge API" absent from public GraphQL and from
gh stack(observed). - The stack-merge creates a merge commit instead of honoring the branch's
rebasemerge-queue method, so itsMerge pull request …message failscommit_message_pattern(inferred from the rule violation).
Workaround
gh stack unstack (PRs keep bases/approvals) → bottom PR enqueues and merges normally.
Suggested fix
- Have stack-merge honor the target branch's merge-queue method (rebase; no merge commit).
- Expose stack-merge via GraphQL + a
gh stack mergecommand. - Fail earlier with a stack-specific message instead of a generic rule violation.
Related (no exact duplicate)
- Discussion "Merge stack" on a stacked PR appears to enqueue only the bottom PR #172 — "'Merge stack' appears to enqueue only the bottom PR"
- Stack merge hangs after partial merge invalidates latest-push approval #174 — "Stack merge hangs after partial merge invalidates latest-push approval"
- rebase when lower branch was squash merged #169 — "rebase when lower branch was squash merged"
Activity
windsornguyen commentedon Jul 30, 2026
Congratulations on officially becoming public preview! 🥳
I re-tested on July 30, 2026 with
gh-stackv0.1.0, which now shipsgh stack mergebacked by the async stack-merge API, so the missing CLI/API recovery path is fixed. Hooray! 🎉However, queue progression remains problematic in the separate issue tracked by #174. All stack layers were initially accepted, but downstream entries were ejected before the bottom layer merged. After it merged, GitHub force-rewrote the remaining heads without requeuing them, so each remaining layer required another
gh stack mergeinvocation.windsornguyen commentedon Jul 31, 2026
I tested the following flow with
gh-stackv0.1.0 this morning:REBASErebasecommit_message_pattern:^((feat|fix|chore|docs|test|refactor): .+|Merge branch .+)Both PRs ultimately merged successfully through the queue! GitHub produced single-parent rebased commits preserving the original conventional commit messages, so no
Merge pull request …commit was synthesized and no commit-message rule violation occurred.The two failures reported in this issue are resolved in v0.1.0, so I believe this issue (#268) can be closed. The separate queue progression issue remains tracked in #174.