Git - Support `subst` drives · Microsoft/vscode#100274

2020-06-16T09:33:09.000Z

Issue Type: Bug 1. Create a subst drive (`mkdir C:\subst_dir && subst Z: C:\subst_dir`) 2. Create a git repo in there (`mkdir Z:\repo && cd /d Z:\repo && git init && echo Hello > test.txt && git add test.txt && git commit -m first`) 3. Open the repo in VSCode (`code repo`) 4. Make some changes to the file and save. Bug effects (non-exhaustive): - The file shown on the explorer sidebar does not show as modified. (Expected results: there should be an "M" annotation and the filename should be in orange, the tooltip should also say "Modified" at the end.) - The source control sidebar lists changes with the full "actual" path `C:\subst_dir\repo\test.txt` (Expected results: it should just show `test.txt` without the full path, and the tooltip will show the full path as `Z:\repo\test.txt`) - When the file is opened, pressing the "Open Changes" button on the toolbar (top-right) does not navigate to the git changes view. - When the git changes view is opened from the source control sidebar, pressing the "Open File" button on the toolbar opens the file on the "actual" path instead of the file in the workspace. If the workspace file was already opened, there will now be two tabs for the same file but with a different path. This starts happening only after I recently updated Git for Windows to `git version 2.27.0.windows.1`. ~~Unfortunately, I don't remember which version I updated it from (it was probably a few months old). I do have another system with a rather old version (`git version 2.16.2.windows.1`) that does not show this behaviour even on lastest stable VSCode.~~ VS Code version: Code 1.46.0 (a5d1cc28bb5da32ec67e86cc50f84c67cc690321, 2020-06-10T09:03:20.462Z) OS version: Windows_NT x64 10.0.18363 System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1992)| |GPU Status|2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled| |Load (avg)|undefined| |Memory (System)|23.86GB (14.54GB free)| |Process Argv|| |Screen Reader|no| |VM|0%| Extensions: none

(15 comments) (15 reactions) (1 assignee)TypeScript (74,848 stars) (10,221 forks)batch import

buggithelp wantedwindows

Description

Issue Type: Bug

Create a subst drive (mkdir C:\subst_dir && subst Z: C:\subst_dir)
Create a git repo in there (mkdir Z:\repo && cd /d Z:\repo && git init && echo Hello > test.txt && git add test.txt && git commit -m first)
Open the repo in VSCode (code repo)
Make some changes to the file and save.

Bug effects (non-exhaustive):

The file shown on the explorer sidebar does not show as modified. (Expected results: there should be an "M" annotation and the filename should be in orange, the tooltip should also say "Modified" at the end.)
The source control sidebar lists changes with the full "actual" path C:\subst_dir\repo\test.txt (Expected results: it should just show test.txt without the full path, and the tooltip will show the full path as Z:\repo\test.txt)
When the file is opened, pressing the "Open Changes" button on the toolbar (top-right) does not navigate to the git changes view.
When the git changes view is opened from the source control sidebar, pressing the "Open File" button on the toolbar opens the file on the "actual" path instead of the file in the workspace. If the workspace file was already opened, there will now be two tabs for the same file but with a different path.

This starts happening only after I recently updated Git for Windows to git version 2.27.0.windows.1. Unfortunately, I don't remember which version I updated it from (it was probably a few months old). I do have another system with a rather old version (git version 2.16.2.windows.1) that does not show this behaviour even on lastest stable VSCode.

VS Code version: Code 1.46.0 (a5d1cc28bb5da32ec67e86cc50f84c67cc690321, 2020-06-10T09:03:20.462Z) OS version: Windows_NT x64 10.0.18363

Item	Value
CPUs	Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1992)
GPU Status	2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled
Load (avg)	undefined
Memory (System)	23.86GB (14.54GB free)
Process Argv
Screen Reader	no
VM	0%

Contributor guide

Tech stack: typescriptshell
Domain: desktoptooling
Issue type: bug
Difficulty: 4
Estimated time: 3-5 days
Activity status: stale
Clarity: clear
Prerequisites: Git basicsWindows file systemVS Code extension development
Newbie friendliness: 30
Research direction: Investigate how VS Code's Git extension handles file paths, particularly for Windows subst drives. Look at the recent Git for Windows update that introduced this behavior. Potential files to explore: src/vs/platform/git/... and src/vs/workbench/contrib/git/... Test with subst drive setup and trace path resolution.