Summary
When using gh stack, it's possible to end up with a PR whose head branch has no commits beyond its base branch (i.e., an empty diff). When this happens, GitHub automatically marks that PR as "merged" as soon as it is synchronized (e.g., via gh stack submit pushing to origin), even though no actual merge was intended.
Repro scenario
Given a stack main <- branch A <- branch B:
- Commit to
A (intending it for B).
- Check out
B from A without making a new commit.
- Push
B and open PRs for A and B.
- Run
gh stack init to adopt the two branches into a stack.
- Run
gh stack submit.
Because B's branch contains no commits beyond A, GitHub treats the PR for B as having "no diff" against its base, and the subsequent push/synchronize causes GitHub to automatically mark PR B as merged into A — even though the user never intended or triggered a merge.
Observed example
After running gh stack init followed by gh stack submit, PR #15 (branch B) was unexpectedly shown as merged into PR #14 (branch A), because branch B had no unique commits relative to branch A.
Request
gh stack should proactively detect this situation (a branch in the stack with no commits ahead of its base) and warn or prevent the user from creating/submitting a PR in that state, rather than letting it silently get auto-merged by GitHub.
Context
Reported by @jschnapper, triaged by @skarim, in a Slack thread.
Created from a Slack conversation.
Summary
When using
gh stack, it's possible to end up with a PR whose head branch has no commits beyond its base branch (i.e., an empty diff). When this happens, GitHub automatically marks that PR as "merged" as soon as it is synchronized (e.g., viagh stack submitpushing to origin), even though no actual merge was intended.Repro scenario
Given a stack
main <- branch A <- branch B:A(intending it forB).BfromAwithout making a new commit.Band open PRs forAandB.gh stack initto adopt the two branches into a stack.gh stack submit.Because
B's branch contains no commits beyondA, GitHub treats the PR forBas having "no diff" against its base, and the subsequent push/synchronize causes GitHub to automatically mark PRBas merged intoA— even though the user never intended or triggered a merge.Observed example
After running
gh stack initfollowed bygh stack submit, PR #15 (branch B) was unexpectedly shown as merged into PR #14 (branch A), because branch B had no unique commits relative to branch A.Request
gh stackshould proactively detect this situation (a branch in the stack with no commits ahead of its base) and warn or prevent the user from creating/submitting a PR in that state, rather than letting it silently get auto-merged by GitHub.Context
Reported by @jschnapper, triaged by @skarim, in a Slack thread.
Created from a Slack conversation.