PRs not shown in panel when workspace folder is a manually-created git worktree

[bkmuraliext]

Extension version

0.144.0

VS Code version

1.110.1 (Windsurf)

OS

macOS Darwin 25.5.0

Steps to reproduce

1. Have a repo at ~/workspace/github/web-controller with open PRs on a feature branch.
2. Create a worktree manually:

   git -C ~/workspace/github/web-controller worktree add \
     ~/workspace/cascade-wt/feature-foo/web-controller \
     -b feature-foo origin/develop
   

3. Open only the worktree directory (~/workspace/cascade-wt/feature-foo/web-controller) as a workspace folder in VS Code / Windsurf.
4. Open the GitHub Pull Requests panel.

Expected behaviour

PRs for the repo (matched via the origin remote) are listed in the panel, just as they are when opening the main repo directory.

Actual behaviour

The GitHub Pull Requests panel shows no PRs and does not recognise the folder as a GitHub repo.

Root cause

A manually-created worktree directory contains a .git file (pointer), not a .git/ directory:

$ cat ~/workspace/cascade-wt/feature-foo/web-controller/.git
gitdir: /Users/me/workspace/github/web-controller/.git/worktrees/web-controller1

The remote configuration lives in the main repo's .git/config, reachable via the commondir pointer inside the worktree-specific git dir:

$ cat /Users/me/workspace/github/web-controller/.git/worktrees/web-controller1/commondir
../..

Git itself follows this chain correctly (git remote -v works from the worktree directory). However the extension's repo-discovery logic appears not to follow the .git file → commondir → main config chain, so it never finds the origin remote and renders no PRs.

Notes

• The Source Control panel (VS Code's built-in git extension) does surface the correct branch and remote from the same worktree directory, confirming the pointer chain is valid.
• Worktrees created by the extension ("Checkout Pull Request in Worktree") may work because the extension tracks those itself; the gap is with worktrees created externally via git worktree add.
• Workaround: also add the main repo directory as a second workspace folder — the panel then finds the real .git/ and shows PRs correctly, but this results in the same files appearing twice in the Explorer.

[bkmuraliext]

Update — correct root cause identified

After deep investigation (reading the extension source + live debug logs), the original root cause description in this issue is incorrect. Updating with what we actually found.

What actually happens

The extension does correctly detect the worktree as a GitHub repo. VS Code's git extension follows the .git file → commondir chain correctly, onDidOpenRepository fires with rootUri = the worktree path, and FolderRepositoryManager is created with the right origin remote. So repo-discovery is not the problem.

The real failure is in how the extension determines which PR to look up for the current branch.

Root cause: wrong headRefName used in the GitHub GraphQL query

In reviewManager.ts getUpstreamUrlAndName():

if (branch.upstream) {
    return {
        remoteName: branch.upstream.remote,
        upstreamBranchName: branch.upstream.name,  // ← the bug
        ...
    };
}

When a worktree is created with:

git worktree add -b feature-foo <path> origin/develop

git sets branch.feature-foo.merge = refs/heads/develop. VS Code's git extension reads this and reports branch.upstream.name = "develop".

The extension then calls getPullRequestForBranch("develop", ...), which issues the GraphQL query:

pullRequests(first: 3, headRefName: "develop", orderBy: { field: CREATED_AT, direction: DESC })

This finds PRs where develop is the HEAD branch — typically an old, closed release/sync PR — not the open PR for feature-foo. The wrong PR is resolved as CLOSED, the panel clears, and no PRs are shown.

Secondary bug: ascending sort picks lowest PR number

In pullRequestGitHelper.ts getMatchingPullRequestMetadataForBranch() (line 336):

const matchingConfigs = allConfigs
    .filter(config => config.key === configKey)
    .sort((a, b) => b.value < a.value ? 1 : -1);  // accidentally ascending
return PullRequestGitHelper.parsePullRequestMetadata(matchingConfigs[0].value);

The comparator (a, b) => b.value < a.value ? 1 : -1 sorts ascending (smaller value first). Since values are "owner#repo#<PR-number>", it always picks the lowest PR number — the oldest PR — even after associateBranchWithPullRequest writes the correct newer PR to git config.

Suggested fix

Bug 1 — in getUpstreamUrlAndName, use the branch's own name as the headRefName when the upstream points at a different branch (e.g. a base/develop tracking ref):

if (branch.upstream) {
    // If the branch tracks a *different* remote branch (e.g. it was created
    // from origin/develop), use the local branch name as the head ref for the
    // GitHub PR query — not the upstream name.  The upstream name is only
    // correct when the branch explicitly tracks its own remote counterpart.
    const upstreamBranchName =
        branch.upstream.name === branch.name
            ? branch.upstream.name
            : branch.name;          // feature branch name, not "develop"
    return { remoteName: branch.upstream.remote, upstreamBranchName, remoteUrl: undefined };
}

Bug 2 — fix the sort to be descending (highest PR number = most recent first):

// Before (ascending — wrong):
.sort((a, b) => b.value < a.value ? 1 : -1)

// After (descending — most recent PR number first):
.sort((a, b) => a.value < b.value ? 1 : -1)

Workaround (until fixed)

After creating a worktree, set the tracking ref to the feature branch itself:

git branch --set-upstream-to=origin/feature-foo feature-foo

This makes branch.upstream.name = "feature-foo", so the extension queries with the correct headRefName. If the remote branch does not exist yet (before first push), set the merge config directly:

git config branch.feature-foo.merge refs/heads/feature-foo

Additional note: git config --add accumulation

associateBranchWithPullRequest calls repository.setConfig(key, value) which maps to git config --add, not git config (replace). Combined with bug 2's ascending sort, this means every state-validation cycle appends another entry and the sort always returns the oldest one. In active sessions this inflates .git/config to thousands of lines. Using git config (replace) instead of git config --add would fix both the accumulation and eliminate the need for the sort entirely.