gh stack init silently recreates an existing branch from trunk (instead of adopting it) when only a remote-tracking ref exists, and submit force-pushes over the real branch, destroying its history and closing its PR

Environment

• gh-stack v0.1.0
• gh 2.97.0
• git 2.50.1
• macOS

Summary

gh stack init <branch> treats a branch as "new" (and creates it fresh from trunk) if no local branch of that exact name exists — even when a remote-tracking ref for it does exist, with real commits and an open PR behind it. gh stack submit then force-pushes that empty, trunk-tip branch over the real remote branch, silently deleting its commits and causing GitHub to auto-close its PR (empty diff → nothing to merge).

Root cause (traced in source)

• internal/git/gitops.go BranchExists calls client.HasLocalBranch(...) — it never checks refs/remotes/<remote>/<name>.
• cmd/init.go's resolveArgBranches treats "not found locally" as "doesn't exist," and runs git.CreateBranch(name, parent) (parent = trunk for the bottom-most branch) — i.e. git branch <name> <trunk>, discarding any relationship to the real branch/PR of the same name.
• The success message still prints "Adopted N branches" regardless of whether a branch was actually adopted or freshly (and destructively) created — no warning is shown.
• cmd/submit.go:227 then unconditionally force-pushes every branch (git.Push(..., force=true, ...), using --force-with-lease under the hood) — the lease only guards against a concurrent change by someone else, not against gh-stack pushing an unrelated commit on purpose.

Repro

1. feature-x exists on origin with real commits and an open PR, based on main.
2. Without ever creating a local branch named feature-x, branch off it under a different name: git checkout -b my-work origin/feature-x.
3. gh stack init feature-x my-work → prints "Adopted 2 branches" but actually ran git branch feature-x main for feature-x.
4. gh stack submit → force-pushes the empty feature-x to origin, wiping its real commits. GitHub auto-closes feature-x's PR since the diff is now empty.

Impact

Silent, unwarned history loss on a shared branch with real, reviewed work behind it. In our case the original commits happened to still be reachable via another local branch built on top before the incident, so we could restore them — anyone without that would have lost the work (short of GitHub's own object retention).

Suggested fix

Before classifying a branch as new in init, also check for a remote-tracking ref (or fetch first); if one exists, create the local branch from it (git branch <name> <remote>/<name> or equivalent) instead of from trunk. Separately, submit/push force-pushing should sanity-check that it isn't collapsing a branch's diff to zero relative to what's currently on the remote, or at minimum surface a loud warning before doing so.