Change:
Type: <bBug</bOn a Windows computer, when opening a project in a directory that contains a symlink to an SMB network location, the source control gutters that show modifications to a file stop working (e.g. green highlighting, red triangles, etc). Also, .gitignored files are no longer grayed out. Steps to reproduce: a repository available over a Windows network sharing path. For example, I am testing with a repository at (this is a path set up by ). a symbolic link to this path. From the Windows Command Prompt, in my scenario, I run: test that the symlink is good - from Command Prompt, this should list files in your repo: Proof that it's a symlink, from Command Prompt: Open the directory in VS Code. Note that some care is necessary here to avoid accidentally dereferencing the symlink, which the file open dialog has a tendency to do. The best way to do this will be to open it from the Command Prompt: Open a file in the repo using the Explorer panel in VS Code, and try making some changes to it. Notice that: (a) hovering over the tab with the mouse shows a tooltip with the opened path: C:repostmptest, (b) if you try to make any edits to the file, no changes are shown in the gutter. By this, I mean the documented do not function. Issue hints at an interesting dimension to the problem. Indeed, if you try to open the Source Control panel, and open the file from there, then the gutter indicators work. Notice the tooltip now shows that the file was opened after dereferencing the symlink, i.e. the original UNC path. If I had to make a guess, the issue must be that the different file paths seen in steps 6/7 above means that the local C: path doesn't appear to VS Code to be "under source control" and thus doesn't show any gutters. I.e. the text editor is not dereferencing, but the Git portion is. Then the paths aren't the same, and thus gutter indicators don't work. (Nor, apparently, graying out files ignored by .gitignore). Related issues: is about opening repositories on symlinked paths. Ostensibly the feature is complete and the issue was closed, but it seems things aren't quite perfect yet. notes a similar issue with subst drives. notes similar behavior to what I saw in step 7, above. notes similar behavior to where .gitignore'd files are not grayed out, under mysterious circumstances that the submitter could not reproduce. None of these issues seem to address this particular circumstance of symlink targets that are UNC paths. (Which is quite common with Vagrant...) Background information about why I am trying to do this Ultimately, what I am doing is using to set up a Windows virtual machine for development, and then using the SSH remote connection feature of VS Code to connect to it. Vagrant automatically sets up symbolic links similar to the ones I described above. (Am I the only person in the world using Vagrant with VS Code and SSH remote connection? Is there something better I've missed? Ideally, I'd rather be using something like Dev Containers, but it seems that this isn't really a thing yet for Windows development - the only VS Code remote connection option I've found is SSH.) Alternative solutions I've tried, and why they don't work: Using the UNC path directly, instead of a network drive, has multiple issues: VS Code doesn't support opening a UNC path when connecting over SSH: VS code says the UNC path doesn't exist (this is false). Command Prompt doesn't support UNC paths anyway as a current directory, so the experience would be suboptimal anyway. Mapped network drives: this isn't how Vagrant works, it doesn't set these up for me. I tried manually creating one anyway, but they don't persist when connecting via SSH. Other methods of sharing folders in Vagrant: categorically ruled out because I assume they're slower / more involved / more finicky than SMB paths, which are generally a proven solution used on Windows for many decades. VS Code version: Code 1.93.1 (, 2024-09-11T17:20:05.685Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please download and install VS Code Insiders 1.95 as it contains a fix for this issue. Thank you!

Discussion:
// Keep trailing spaces which are part of the directory name const repositoryRootPath = path.normalize(result.stdout.trimStart().replace(/[rn]+$/, '')); <ins> // Handle symbolic links and UNC paths // Git 2.31 added the `--path-format` flag to rev-parse which // allows us to get the relative path of the repository root if (!pathEquals(pathInsidePossibleRepository, repositoryRootPath) && !isDescendant(repositoryRootPath, pathInsidePossibleRepository) && !isDescendant(pathInsidePossibleRepository, repositoryRootPath) && this.compareGitVersionTo('2.31.0') !== -1) { const relativePathResult = await this.exec(pathInsidePossibleRepository, ['rev-parse', '--path-format=relative', '--show-toplevel',]); return path.resolve(pathInsidePossibleRepository, relativePathResult.stdout.trimStart().replace(/[rn]+$/, '')); } </ins> if (isWindows) { // On Git 2.25+ if you call `rev-parse --show-toplevel` on a mapped drive, instead of getting the mapped // drive path back, you get the UNC path for the mapped drive. So we will try to normalize it back to the

} } <del> // Handle symbolic links // Git 2.31 added the `--path-format` flag to rev-parse which // allows us to get the relative path of the repository root if (!pathEquals(pathInsidePossibleRepository, repositoryRootPath) && !isDescendant(repositoryRootPath, pathInsidePossibleRepository) && !isDescendant(pathInsidePossibleRepository, repositoryRootPath) && this.compareGitVersionTo('2.31.0') !== -1) { const relativePathResult = await this.exec(pathInsidePossibleRepository, ['rev-parse', '--path-format=relative', '--show-toplevel',]); return path.resolve(pathInsidePossibleRepository, relativePathResult.stdout.trimStart().replace(/[rn]+$/, '')); } </del> return repositoryRootPath; }