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

Aberta
#9,156 0 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@alexr00 já está trabalhando nisso.

Desde 3/11/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

  • 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.

Linguagem predominante
TypeScript
Estrelas
2.6k
Forks
811
Merge médio
1d 8h
PRs com merge (30d)
70

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/vscode-pull-request-github

Todas as issues de microsoft/vscode-pull-request-github

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.