Describe the bug
When a branch's upstream is configured to track a local sibling branch rather than a remote-tracking branch — the pattern used by stacked-PR tooling (e.g. Graphite, git-branchless, or similar internal stacking tools), where branch.<name>.remote is set to . and branch.<name>.merge points at refs/heads/<other-local-branch> — the extension's background polling repeatedly throws:
Error: The upstream ref <ref> for branch <branch> is not a GitHub repo.
at gy.getOrigin
at async gy.getPullRequestDefaults
at async by.getPullRequestsForQuery
at async R6._pollForChanges
As a side effect, the native VS Code git blame hover (git.blame.editorDecoration.enabled) stops showing its full-commit-message hover popup on any file while that branch is checked out — only the one-line inline decoration still renders. Switching to a branch whose upstream is a normal origin remote branch immediately restores the full hover popup, isolating the cause to this upstream configuration rather than anything else.
To Reproduce
- In a repo with a GitHub remote
origin, create two local branches, e.g. feature-a and feature-b (feature-b branched from feature-a).
- Set
feature-b's upstream to track feature-a locally instead of a remote:
git config branch.feature-b.remote .
git config branch.feature-b.merge refs/heads/feature-a
- Open the repo in VS Code with this extension installed and signed in, with
feature-b checked out.
- Open
View → Output → Log (Extension Host) and observe the repeated error above.
- Enable
git.blame.editorDecoration.enabled and hover over a blame-decorated line — no full-commit hover panel appears (only the inline one-liner).
Expected behavior
The extension should recognize that the branch's upstream isn't itself a hosted remote, skip/no-op the PR-defaults resolution for that branch gracefully, and not interfere with the native git blame hover on other branches or files.
Environment
- VS Code 1.133.0
- GitHub Pull Requests and Issues extension 0.162.0
- Ubuntu 22.04.5 LTS, Linux kernel 6.8.0-136-generic, x86_64
- git 2.52.0
Describe the bug
When a branch's upstream is configured to track a local sibling branch rather than a remote-tracking branch — the pattern used by stacked-PR tooling (e.g. Graphite, git-branchless, or similar internal stacking tools), where
branch.<name>.remoteis set to.andbranch.<name>.mergepoints atrefs/heads/<other-local-branch>— the extension's background polling repeatedly throws:As a side effect, the native VS Code git blame hover (
git.blame.editorDecoration.enabled) stops showing its full-commit-message hover popup on any file while that branch is checked out — only the one-line inline decoration still renders. Switching to a branch whose upstream is a normaloriginremote branch immediately restores the full hover popup, isolating the cause to this upstream configuration rather than anything else.To Reproduce
origin, create two local branches, e.g.feature-aandfeature-b(feature-bbranched fromfeature-a).feature-b's upstream to trackfeature-alocally instead of a remote:feature-bchecked out.View → Output → Log (Extension Host)and observe the repeated error above.git.blame.editorDecoration.enabledand hover over a blame-decorated line — no full-commit hover panel appears (only the inline one-liner).Expected behavior
The extension should recognize that the branch's upstream isn't itself a hosted remote, skip/no-op the PR-defaults resolution for that branch gracefully, and not interfere with the native git blame hover on other branches or files.
Environment