Git: Support `subst` drives
See original GitHub issueIssue 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 showtest.txt
without the full path, and the tooltip will show the full path asZ:\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® Core™ 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% |
Issue Analytics
- State:
- Created 3 years ago
- Reactions:6
- Comments:9 (1 by maintainers)
Top Results From Across the Web
Git not properly working on a substituted drive (created via the ...
Hi there, Note that Git (source control) doesn't seem to work properly with a Visual Studio solution opened on a substituted drive (created ......
Read more >Re: Git bug - Windows subst/net use, Windows drive letter prefix
On Thu, Jul 16, 2020 at 11:03:22AM +0000, Paul D. Smith wrote: > I believe there is a subtle bug in Git that...
Read more >subst
Reference article for the subst command, which associates a path with a drive letter.
Read more >Change drive in git bash for windows
remove the colon after the drive letter; replace your back-slashes with forward-slashes; If you have blank spaces in your path: Put quotation ...
Read more >Git - gitattributes Documentation
If a Git client that does not support the working-tree-encoding attribute adds a new file bar.ps1 , then bar.ps1 will be stored "as-is"...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I as well would like this to be fixed. Because of this gitlens and other stuff does not work properly (e.g. no line history - author who changed line - does work)
Update: I tested some of the older releases of Git for Windows and confirmed that it worked as expected on 2.24.1(2) and fails starting from 2.25.0.