Skip to content

git: route linked-worktree files to the correct window - #335634

Open
Mr Majumder (D-Majumder) wants to merge 2 commits into
microsoft:mainfrom
D-Majumder:fix/290708-linked-worktree-window
Open

git: route linked-worktree files to the correct window#335634
Mr Majumder (D-Majumder) wants to merge 2 commits into
microsoft:mainfrom
D-Majumder:fix/290708-linked-worktree-window

Conversation

@D-Majumder

Copy link
Copy Markdown

Fixes #290708

Related to #299540 (same underlying root cause, reported independently).

Bug

When multiple VS Code windows are open, one per Git worktree, operations that write into a linked worktree's private Git metadata — such as git commit with core.editor set to code --wait, or a rebase — can open the editor in the main worktree's window instead of the linked worktree's window.

Root cause

findWindowOnFile normally selects a window by checking whether the target file is a child of an open window's folder. Git linked worktrees store their private per-worktree files under the main worktree's .git/worktrees/<name>/ directory, so those files appear to belong to the main worktree rather than the linked worktree.

Fix

Recognize Git linked-worktree metadata paths before the existing parent-folder matching and resolve the linked worktree through its .git pointer file. The comparison uses the full resolved worktree metadata path so unrelated repositories with the same worktree name cannot be confused.

Ordinary repositories, normal files, non-file URIs, and existing fallback behavior remain unchanged.

Tests

Added regression coverage for:

  • linked-worktree metadata routing to the correct window
  • fallback to existing behavior when there is no matching linked-worktree window
  • paths that merely resemble Git worktree metadata
  • two unrelated repositories using the same worktree name

Validation

  • git diff --check — passed
  • Node syntax checks on both changed files — passed
  • Standalone algorithm verification — 6/6 assertions passed

The repository's actual windowsFinder.test.ts suite was not run locally because this environment has Node v22.23.1, while VS Code requires Node v24.18.0. No compatible Node version manager or vendored Node binary was available, so no dependency installation was attempted. CI/maintainer validation is therefore requested for the full test suite.

…, microsoft#299540)

findWindowOnFile matched windows by simple parent-folder containment of
a file's path. Git linked worktrees store their private per-worktree
files (COMMIT_EDITMSG, rebase-merge/git-rebase-todo, etc.) inside the
*main* worktree's .git/worktrees/<name> directory rather than under the
linked worktree's own folder, so such files always resolved to the main
worktree's window instead of the correct linked-worktree window (e.g.
when core.editor is "code --wait").

Add findWindowOnGitWorktreeFile, checked before the existing
parent-folder matching: it recognizes .git/worktrees/<name> metadata
paths and, by resolving each candidate window's own .git pointer file,
matches against the full worktree directory path rather than just the
trailing <name> segment, so two unrelated repositories that happen to
share a worktree name cannot be confused with one another. Ordinary
repositories (.git as a directory) and non-worktree files are
unaffected and never trigger the new filesystem read.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TzTiUkg9L2rajTg9eb9zxY
Copilot AI balanced review requested due to automatic review settings September 11, 2026 07:23

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Linked worktrees opened within multi-root workspaces are ignored and can still route to the wrong window.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Routes Git linked-worktree metadata files to the window containing the corresponding worktree.

Changes:

  • Resolves worktrees through their .git pointer files.
  • Adds regression coverage for routing and repository-name collisions.
File summaries
File Description
windowsFinder.ts Adds linked-worktree-aware window selection.
windowsFinder.test.ts Adds filesystem-backed routing tests.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 1
  • Review effort level: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +54 to +55
const openedFolder = isSingleFolderWorkspaceIdentifier(window.openedWorkspace) ? window.openedWorkspace.uri : undefined;
if (!openedFolder || openedFolder.scheme !== Schemas.file) {
@D-Majumder

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree

findWindowOnGitWorktreeFile only checked single-folder windows when
matching a linked worktree's .git pointer file, so a linked worktree
opened as one folder of a multi-root workspace was skipped and could
still route to the main worktree's window. Resolve IWorkspaceIdentifier
folders through the existing localWorkspaceResolver, matching how the
surrounding findWindowOnFile fallback logic already handles multi-root
workspaces. Unresolved workspaces are skipped gracefully, as before.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TzTiUkg9L2rajTg9eb9zxY
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

If multiple instances of VSCode are opened for different git worktrees, the git editor is opened in the main worktree VSCode instance

3 participants