Checkout Pull Request in Worktree still fetches fork head from base remote in 0.174.0
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
- Clone a fork and configure remotes such as:
origin: your forkupstream: the repository receiving the PRcontributor: the fork containing the PR's head branch
- Open a PR against the upstream repository whose head branch exists only in the contributor's fork.
- In the GitHub Pull Requests view, choose Checkout Pull Request in Worktree and select a new directory.
- 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 9h
- PRs com merge (30d)
- 69
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
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de microsoft/vscode-pull-request-github
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
microsoft/vscode-pull-request-github#9159 ·
Mantenedores costumam responder em até 1 dia
-
Merging from the PR description tab shows "Error refreshing pull request description: Webview is disposed"Talvez já em andamento @alexr00 assumiu há 2 dias. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
microsoft/vscode-pull-request-github#9143 · 1 reação · 2 responsáveis ·
Mantenedores costumam responder em até 1 dia
-
Honor open-to-side placement when opening GitHub PR and issue linksTalvez já em andamento @alexr00 assumiu há 2 dias. Abertafeature-request
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
microsoft/vscode-pull-request-github#9072 · 1 reação · 2 responsáveis ·
Mantenedores costumam responder em até 1 dia
-
Resolve Conflicts doesn’t open in VS Code Desktop with a GitHub Remote RepositoryTalvez já em andamento @alexr00 assumiu há 1 dia. Aberta
microsoft/vscode-pull-request-github#9158 · 1 comentário · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
Show loading feedback while Comment and Resolve is resolving a threadTalvez já em andamento @alexr00 assumiu há 2 dias. Aberta
microsoft/vscode-pull-request-github#9155 · 1 responsável ·
Mantenedores costumam responder em até 1 dia
Todas as issues de microsoft/vscode-pull-request-github
Issues semelhantes
-
[fullsend] E2E: scorecard — filecheck GitLab entity metrics unavailable due to initialDelay timingAbertae2e-failure ready-to-code
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
redhat-developer/rhdh-plugin-export-overlays#4698 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
devswha/herdr-web-ui#2884 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
b:minor bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
software-mansion/argent#1771 ·
Mantenedores costumam responder em até 1 dia
-
Resources: New palettes of XiamenTalvez já em andamento @rmt-svc assumiu hoje. Abertaresources
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 74/100
railmapgen/rmg-palette#2491 ·
Mantenedores costumam responder em até 4 dias