creating a stack for existing PRs fails and force pushes an unrelated old commit

[sddavis]

1. create a branch from main
2. commit a change
3. commit another change
4. create a PR for the first commit with main as its base
5. create a PR for the second commit with the first commit's branch as its base
6. gh stack init first-pr-branch second-pr-branch
7. gh stack submit

Expected: the PRs are unchanged other than being linked in a stack

Actual:

• gh stack submit fails with error

Checking stack state...
Pushing to github...
⚠ failed to update base branch for PR #1789: HTTP 422: Validation Failed (https://api.github.com/repos/EP-Hub/com.tasktop.data/pulls/1789)
PullRequest.base is invalid

• the second PR is closed and has 0 commits
• the first PR has been force pushed with an unrelated commit from 7 weeks ago

I have tried this 4 times using different branch names and it always does the same thing, always pushing the same old commit to the first PR.

[sddavis]

Update: if I create local branches from the remote PR branches, I still get the "failed to update base branch" message but it otherwise works correctly. So when running gh stack init first-pr-branch second-pr-branch it's necessary to have local branches named first-pr-branch and second-pr-branch; if only origin/first-pr-branch and origin/second-pr-branch exist, it behaves as above. It should not be necessary to create local branches.

[sddavis]

I tried passing the full remote branch names, gh stack init refs/remotes/origin/first-pr-branch refs/remotes/origin/second-pr-branch, but it created a new branch refs/heads/refs/remotes/origin/first-pr-branch and then failed because the existence of this branch made refs/remotes/origin/first-pr-branch ambiguous. This branch points to the old commit that was being pushed, so I guess the problem is actually in gh stack init.

[sddavis]

I'm guessing this old commit is selected because I happen to have a local branch named master pointing at it (unless gh stack did that).

[zbmott]

The behavior is actually worse than you've described.

I did:

gh stack init --base my-base branch-1 branch-2 branch-3
gh stack submit

The three topic branches existed on the remote, each with its own commits and an open PR, but they didn't exist locally because I had developed them on another machine. gh stack init matches its branch arguments against local refs only. Finding no local branch by those names, it treated all three as missing and created fresh, empty branches off the base (my-base at abcdef123). During stack reconciliation it then force-pushed those empty branches over the remote refs, which reset each PR's head to equal its base (empty diff) and closed all three PRs.

The original work was not in the local object store and was gone from the remote refs. I was only able to recover it because GitHub's HeadRefForcePushedEvent still recorded the pre-push tips, which allowed me to recover via a fetch by SHA, a branch reset, a force-push to restore, and a PR reopen.

This is... not safe design.

1. It matches on local refs but writes to remote refs. Any branch you name that you haven't checked out locally is invisible to the adopt logic, yet fully in scope to be destroyed.
2. A name collision is treated as an instruction to overwrite. Instead of adopting the remote branch of the same name, or refusing and reporting "these branches already exist on the remote with open PRs," it silently replaces their content and closes their PRs.
3. --force-with-lease provides no protection here. The lease matched, because the empty branch it built was based on the current remote tip. The lease guards against a stale local view of the remote, not against pushing the wrong content.
4. It is destructive with no preview and no confirmation. There is no dry-run and no diff of what it will adopt versus create versus overwrite. A command named init performed an irreversible push --force plus PR closure.
5. Recovery depended on an external audit log. Nothing local survived. Had GitHub not retained the force-push event and the unreferenced objects, the work would have been unrecoverable.

Until this is fixed always fetch every branch you name into a local tracking branch before gh stack init, or skip init for existing PRs and use gh stack checkout <pr> or gh stack link, which operate on the GitHub PRs directly rather than reconstructing branches from a base.