[Bug]: Pushing a stack in one git push gives every PR above the bottom duplicate CI runs #628

Describe the bug

When a PR's head branch and its base branch are updated in the same git push, GitHub sends that PR two pull_request synchronize events for one commit. Every workflow starts twice. With a per-PR concurrency group, one run cancels the other, and the cancelled run's checks stay on the commit, so the PR shows as failing until that run is re-run in full.

gh stack push pushes all branches in one push, so every PR above the bottom of a stack is affected on every update. --no-atomic does not change this.

Affected command

gh stack push

gh-stack version

gh stack version 0.3.0

GitHub CLI version

gh version 2.104.0 (2026-11-12)

Operating system

macOS 27.2

Shell

zsh

Steps to reproduce

In a repo with one pull_request workflow (types: [opened, synchronize, reopened]) and a stack of two PRs, A based on main and B on top of A:

1. Commit to A's branch and merge it into B's branch.
2. Run gh stack push.
3. Count the workflow runs for B's new head commit.

Expected behavior

One run per workflow for each PR.

Actual behavior

The plain git push rows give the same result whether or not the two PRs are linked as a stack on GitHub.

The two events' payloads are byte-identical (action, before, after, head and base commits), so a workflow cannot detect or skip the duplicate.

Suggested fix: push each branch with its own git push, bottom of the stack first. In our tests this needed no pause between the pushes. #466 proposes an opt-in --stagger <duration> flag; we think a delay is unnecessary and that an opt-in flag leaves the default broken.

Terminal output

N/A

Preflight checks

• I searched the existing issues for duplicates. Add --stagger <duration> to space out branch pushes and avoid duplicate CI runs #466 describes the same cause but asks for an opt-in delay; this issue is about the default behavior.
• I ran gh extension upgrade stack and reproduced this issue on the latest stable release.

cc @skarim