`gh stack submit` fails when remote uses a custom SSH host alias

[EricCrosson]

gh stack submit exits with an error when the git remote URL uses a custom SSH host alias (e.g. github.com-work) instead of the literal github.com hostname. There is no flag to override the repository, so submit is unusable in this configuration.

Steps to reproduce

1. Configure ~/.ssh/config with a host alias (common for multi-account setups):

   Host github.com-work
       HostName github.com
       User git
       IdentityFile ~/.ssh/id_ed25519_work
   

2. Clone using the alias:

   git clone git@github.com-work:org/repo.git
   cd repo
   

   git remote get-url origin → git@github.com-work:org/repo.git

3. Initialize a stack and submit:

   git checkout -b layer-1 && git commit --allow-empty -m "layer 1"
   git checkout -b layer-2 && git commit --allow-empty -m "layer 2"
   git checkout layer-1
   gh stack init --adopt -b main layer-1 layer-2
   gh stack submit --draft
   

Actual result

✗ failed to create GitHub client: determining repository: unable to determine current
repository, none of the git remotes configured for this repository point to a known
GitHub host

The --remote origin flag and GH_HOST=github.com env var do not help — the error
is identical with both.

Expected result

gh stack submit pushes the branches and opens draft PRs, the same as it would with a git@github.com:org/repo.git remote.

What I tried

• gh stack submit --remote origin — same error
• GH_HOST=github.com gh stack submit — same error
• GH_REPO=org/repo gh stack submit — gets past host detection, but then pushes to
  git@github.com:org/repo.git instead of the configured alias, so the push fails
  with a key-agent rejection

Workaround

Push branches manually and create PRs one at a time:

git push origin layer-1 layer-2
gh pr create --draft --repo org/repo --base main   --head layer-1 --title "layer 1"
gh pr create --draft --repo org/repo --base layer-1 --head layer-2 --title "layer 2"

Environment

gh version 2.89.0 (nixpkgs)
gh extension: gh stack (github/gh-stack)
OS: macOS
Remote URL format: git@github.com-<alias>:org/repo.git

[benekuehn]

I opened an upstream fix in cli/go-gh#274. The root cause is in repository.Current: it translates SSH alias URLs, but continues filtering with cached repository metadata from before translation. The PR refreshes that metadata while preserving fetch/push precedence and includes a regression test for the github.com-work case.

This will still need to merge and then be consumed by gh-stack before the issue is resolved.

[RishabJaiswal]

Facing the same.
It quite a common usecase when a user has multiple github account

[albinofreitasrunflow]

Hit this today with the same multi-account setup (Host github.com-<org> → HostName github.com in ~/.ssh/config).

One data point that may help scope the fix: the core gh CLI resolves the alias fine — gh repo view and gh pr list correctly identify the repository with only the aliased remote configured. It's only the extension that fails with unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host, so it looks like the alias translation that gh does via ssh -G/~/.ssh/config isn't wired up in the extension's remote resolution.

Workaround we're using: add a second HTTPS remote (git remote add ghstack https://github.com/org/repo.git) and pass --remote ghstack to submit/push/sync/rebase. Two gaps remain with that workaround:

• checkout <stack-number>, trunk, and modify accept no --remote flag, and with two remotes and no remote.pushDefault they fail non-interactively.
• Setting remote.pushDefault to the HTTPS remote fixes those but reroutes plain git push away from the SSH remote, which defeats the per-repo identity pinning that motivates the alias setup in the first place.

Translating aliases the same way the core CLI does would make the extension work out of the box for multi-account users.

[benekuehn]

Thanks @albinofreitasrunflow.

Translating aliases the same way the core CLI does would make the extension work out of the box for multi-account users.

I think that's the wrong way. It's just putting again a patch over the shortcoming of go-gh and wouldn't solve it for other consumers hence my proposal cli/go-gh#274.