Summary
gh stack link refuses a pull request that has auto-merge enabled, so adopting a stack costs a capability that an unstacked pull request keeps. Every layer then needs a person at the keyboard at the moment the layer below lands.
Evidence
Both pull requests approved and green. #101 had auto-merge enabled, so linking failed:
Checking existing stacks...
Looking up PRs for 2 branches...
✗ PR #101 cannot be added to a stack: it has auto-merge enabled
Turning auto-merge off let the link succeed.
This compounds the behaviour in #174. When the bottom layer merges, the layer above leaves the queue and GitHub rewrites its head, which restarts its required checks. Nothing puts it back. With auto-merge unavailable, only a person can, and only once the restarted checks finish. A stack of three with a 15-minute required check needs three waits and three manual enqueues to land one change.
Expected
A stacked pull request can use auto-merge, so each layer enqueues itself once its base merges and its checks pass.
If the two genuinely cannot coexist, say so where the user meets it: gh stack link should explain why auto-merge and stacks are exclusive, and the stack panel should say that each layer needs a manual enqueue.
Actual
gh stack link rejects the pull request with no explanation of the conflict, and offers no alternative.
Environment
gh 2.100.0, gh stack v0.0.8
- Trunk protected by a merge queue,
merge_method: REBASE
- Two-layer stack, both pull requests approved with required checks passing
Reproduction
- Open two pull requests that stack on each other, both approved and green.
- Enable auto-merge on the bottom one.
- Run
gh stack link <bottom> <top>.
Note on scope
This reports only what was observed: gh stack link rejects a pull request that already has auto-merge enabled. The reverse direction, enabling auto-merge on a pull request that is already stacked, was not tested, because the repository in question has allow_auto_merge: false set at the repository level for unrelated reasons.
Related
Summary
gh stack linkrefuses a pull request that has auto-merge enabled, so adopting a stack costs a capability that an unstacked pull request keeps. Every layer then needs a person at the keyboard at the moment the layer below lands.Evidence
Both pull requests approved and green.
#101had auto-merge enabled, so linking failed:Turning auto-merge off let the link succeed.
This compounds the behaviour in #174. When the bottom layer merges, the layer above leaves the queue and GitHub rewrites its head, which restarts its required checks. Nothing puts it back. With auto-merge unavailable, only a person can, and only once the restarted checks finish. A stack of three with a 15-minute required check needs three waits and three manual enqueues to land one change.
Expected
A stacked pull request can use auto-merge, so each layer enqueues itself once its base merges and its checks pass.
If the two genuinely cannot coexist, say so where the user meets it:
gh stack linkshould explain why auto-merge and stacks are exclusive, and the stack panel should say that each layer needs a manual enqueue.Actual
gh stack linkrejects the pull request with no explanation of the conflict, and offers no alternative.Environment
gh2.100.0,gh stackv0.0.8merge_method: REBASEReproduction
gh stack link <bottom> <top>.Note on scope
This reports only what was observed:
gh stack linkrejects a pull request that already has auto-merge enabled. The reverse direction, enabling auto-merge on a pull request that is already stacked, was not tested, because the repository in question hasallow_auto_merge: falseset at the repository level for unrelated reasons.Related