init writes branch.<name>.remote = '.', so submit reports a push that never happened

[greatnessinabox]

Environment

• gh 2.96.0 (2026-07-02), gh-stack v0.0.4, git 2.46.1, macOS 26.6
• Run inside a git worktree (GIT_DIR=.git/worktrees/<name>)
• origin is the canonical repo name, not a rename

Summary

gh stack init wrote branch.<name>.remote = . into git config. . means this local repository, so the subsequent gh stack submit pushed nowhere, printed Pushing to ...., and still reported ✓ Pushed and synced 2 branches. The branches did not exist on origin.

This is the same failure as #461 and the same family as #472, but a different trigger. There the cause was a renamed repo; here it is the remote config that init itself wrote.

Repro

git worktree add ../wt -b feature/a
# ... commit on feature/a, then branch feature/b on top, commit
gh stack init --base develop feature/a feature/b
git config --get-regexp 'branch\.feature.*remote'

Observed:

branch.feature/a.remote .
branch.feature/b.remote .

Every other branch in the same repo that was not created by gh stack init has remote origin.

Then:

gh stack submit --auto

Checking stack state...
Pushing to ....
⚠ failed to create PR for feature/a: creating PR: GraphQL: Head sha can't be blank,
  Base sha can't be blank, No commits between develop and feature/a,
  Head ref must be a branch (createPullRequest)
✓ Pushed and synced 2 branches

git ls-remote --heads origin 'feature/*' returns nothing. The push never happened, but the last line says it did. The PR-creation error is a downstream symptom: GitHub cannot see a branch that was never pushed.

Workaround

git push origin feature/a feature/b
git branch --set-upstream-to=origin/feature/a feature/a
git branch --set-upstream-to=origin/feature/b feature/b

After that, gh stack submit prints Pushing to origin... and works correctly. The stack view and the GitHub-side stack were unaffected throughout.

Why it matters

The empty remote name renders as Pushing to ...., which reads as ordinary progress ellipsis rather than an empty value, so there is nothing on screen to notice. Combined with the unconditional ✓ Pushed and synced line, the command looks like it succeeded. I only caught it because PR creation happened to fail in the same run; on a stack where the PRs already exist, submit would report success and silently push nothing.

Given #461 and #472 report the same shape from different causes, the general fix may be for submit to verify the push landed rather than trusting it, and to refuse an empty or . remote outright.

Note

I have not isolated whether the worktree is required to reproduce. It may be related to #459, which reports that gh-stack ties local state to $GIT_DIR and that a worktree changes it.