Checkout Pull Request in Worktree still fetches fork head from base remote in 0.174.0

Open
  • Is something wrong?
#9,156 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@alexr00 is already working on this.

Since Nov 3, 2026.

Assessment

This issue has not been assessed yet.

Description

  • Extension version: GitHub Pull Requests 0.174.0
  • VS Code version: 1.144.0
  • OS: macOS 15.5, Apple Silicon (arm64)
  • Repository clone configuration: fork of an upstream repository, with multiple remotes and linked worktrees
  • GitHub product: GitHub.com

Related: #8983, which is closed as completed. This report confirms that the same failure remains reproducible with the installed, unmodified 0.174.0 extension. I have not established whether the fix for #8983 was included in this release.

Steps to reproduce
  1. Clone a fork and configure remotes such as:
    • origin: your fork
    • upstream: the repository receiving the PR
    • contributor: the fork containing the PR's head branch
  2. Open a PR against the upstream repository whose head branch exists only in the contributor's fork.
  3. In the GitHub Pull Requests view, choose Checkout Pull Request in Worktree and select a new directory.
  4. Observe that creation fails, even though the head branch can be fetched successfully from the contributor remote.
Actual behavior

The extension attempts to fetch the fork's head branch from the base repository remote.

Sanitized excerpts from the original logs (branch name replaced with a placeholder):

2026-11-02 17:50:53.859 [info] > git fetch upstream <fork-only-branch> [1896ms]
2026-11-02 17:50:53.859 [info] fatal: couldn't find remote ref <fork-only-branch>
2026-11-02 17:50:54.495 [error] [Worktree] Failed to create worktree: Failed to execute git

The UI only shows the generic Failed to execute git error, so the incorrect remote is visible only in the Git output.

The failed attempt above was made after removing an earlier local workaround and updating VS Code and the extension. The bundled checkoutPRInWorktree implementation in the unmodified 0.174.0 extension still obtains the remote from pullRequestModel.remote.remoteName and fetches prHead.ref from that remote.

Expected behavior

Resolve the remote corresponding to the PR's head repository and fetch the head branch from it, reusing or creating the contributor remote as needed. Use that same remote when selecting the worktree's starting remote-tracking branch.

Workaround / possible fix

Reusing the existing PullRequestGitHelper.createRemote(repository, pullRequestModel.remote, prHead.repositoryCloneUrl) helper before the fetch fixes remote selection locally. Use the returned remote name both for the fetch and for the remote-tracking branch passed to worktree creation.

With this approach, the original UI command was verified to fetch from the contributor remote and successfully create and open a worktree on 0.144.0. I have restored an equivalent local workaround for 0.174.0; the logged failure above is from the unmodified release, not the patched version.

A regression test with a head branch present only on a fork, plus a base remote named upstream, would help cover this topology.

Dominant language
TypeScript
Stars
2.6k
Forks
811
Avg merge
1d 9h
Merged PRs (30d)
69

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/vscode-pull-request-github

All issues in microsoft/vscode-pull-request-github

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.