Git: Symlink support

[mrded]

• VSCode Version: 1.0.0 (1.0.0)
• OS Version: OSX 10.11.4 (15E65)

Steps to Reproduce:

1. Create a new project with git repository initialised.
2. Create a folder /foo/bar
3. Add a symlink from /foo/bar to /bar ln -s /foo/bar .
4. Go to Git tab on vscode, and stage /bar folder.

If now you click on staged /bar folder, you'll get an error Warn: Can't open this git resource.

[jeremyjjbrown]

It would be nice to find nested git repos as well. Some of us are fortunate enough to not code on Monoliths.

[mightypenguin]

It would be nice to have an option to NOT do GIT change tracking inside symlinks. If my symlink is to another folder in the same git repo I don't want the changed files showing up twice in Code's Git view.

[joaomoreno]

This issue is about displaying symlinks in the git view and what happens when you click them. Neither Code nor git follow (or should follow) the symlinks.

[mightypenguin]

Ok, off topic, but I am seeing VScode following symlinks in the git view. Running "git status" does not show these files. Should I create a new issue or discuss this somewhere else?

[joaomoreno]

Can you take a screenshot to show me what you mean?

[mightypenguin]

I know what causes it.
The git repo is a remotely mounted fuse file system.
The linux terminal shows permissions and symlinks properly, but for some reason vscode isn't.
If I create a simple git repo with a directory and a symlink to that directly it works properly on my local filesystem. If I move that to the fuse mounted file system it confuses vscode.

Here's my mount command:
sshfs hostname:/home/user/ /home/user/ -o sshfs_sync -o sync_readdir -o follow_symlinks -o kernel_cache -o max_background=50 -o big_writes

[joaomoreno]

Actually, no more errors when you click it. We handle it nicely, even with decorations.

[joaomoreno]

We just can't handle the root being a symlink in itself.

[NightMachinery]

VSCode just crashed my Macbook when editing files inside a symlink that pointed to its parent (/project/src -> /project). Fix your infinite loops.

[wscnd]

@dbaeumer Was having the same issue described in microsoft/vscode-eslint#309 when opening symlink project folders, it seems to me that it's related to this one.

[martindale]

I'm adding another $300 bounty to this issue; as mind-boggling as it is to see it still be a problem 5 years later, we're still losing productivity to the crashes and long delays associated with the occasional use of SSHFS for remote editing.

[dragonly]

Currently the local issue is fixed.
But when I use Remote - SSH extension, and open a symbolic linked git repo, the file changes are gone.

[excelsi0r]

I am but a beginner but I've stumbled in this bug (feature?) while migrating from my Ubuntu workstation to a Windows environment. My VsCode explorer git colours were not showing, until the real path was used instead of the symlink.

For anyone like me who would like some dirty fix, just pipe the resolved path to code. From inside the WLS: realpath [SOMEPATH] | xargs code. To avoid typing all that every time, define a function (I saved it in my .zshrc, but it should work identically in bash):

function vscode{ realpath $1 | xargs code }

So you'd just go: vscode [SOMEPATH] instead of code [SOMEPATH]. I really hope this will get sorted out soon(tm).

Add some issues in bash
This did the trick in ~/.bashrc:

function vscode { realpath $1 | xargs code; }

[Migelo]

Just chiming in that I support solving this issue as I lost about a two days trying to get my git gutter indicators to shown, only to realize my home folder on the remote machine is symlinked.

[adekmaulana]

this is the most annoying bug i've ever encountered yet still not fixed after 5 years.
Hope it will be fixed soon

[macsz]

Was reported in 1.0.0, I am on 1.61.0-insider and it still does not work 😢 While not a show stopper, it is certainly an inconvenience when working on a distributed setup.

For anyone looking for a work-around: I do find GitLens extension's Gutter Changes view a functional replacement for built-in gutter indicators. You just have to go to settings and enable it for all files (by default you have to toggle it on for each file separately). It works just fine on both shared/NFS mounts and local directories.

[fsievers]

I'm affected by the same bug. I need this symlink support, because all my projects reside in a directory on another mount-point and symlinked into my home directory.

[AlexHarn]

Still a very annoying issue for me too. I work a lot on cluster dev nodes via SSH and the entire home dir is dynamically loaded through symlinks, no way of replacing it with absolute paths.

[wcheek]

Agreed. This needs to get fixed.

[samarth-robo]

This issue affects ROS uses who symlink various directories in the src directory of their catkin workspace.

[marcitqualab]

Main description.

I have found different problems when adding a folder to the workspace / open a project when that project is in a path with a symbolic link on a parent directory.

For example. /home/user/project being a symbolic link to /home/user/other/customer/whatever/projects.

This issue is not related to any language, extension or configuration settings. I had this problem with totally different projects and computers.

Steps to reproduce:

1. Create a sample project in a directory structure few levels deep in /home/user. i.e /home/user/a/b/c/d/project
2. Create symbolic link /home/user/project -> /home/user/a/b/c/d/project
3. Open folder or Add folder to workspace using the symbolic link /home/user/project
4. Try to run tests using Test Explorer

Actual: Looks like the tests are running but test status never change from not runned status.
Expected: Tests are actually runned and report the correct test status, pass or fail.

Notes

With this scenario I had found at least two problems.

1. Git status coloring of changed files was not working well. There is an open issue for this already.

2. In a Python project, the Test Explorer finds the tests but is not running the tests. The icons to run the tests are not available either when editing test files, at least with pytest.

I suspect that many other issues would have the same root cause.

Mean while this is not fixed. Maybe useful to at least add a warning or notes in the main documentation that opening a new project from a path with symbolic links might include some inconsistencies.

[byerun]

This problem also occurs on Windows when the drive portion of the path pointing to the git project is a subst drive. For example, if I open vscode as shown below I don't see git related modifications shown in the gutter nor does the commit history show up in the timeline view:

subst p: c:\Users\Byron\dev\projects\
code p:\project1

[starfishpatkhoo]

This problem also occurs on Windows when the drive portion of the path pointing to the git project is a subst drive. For example, if I open vscode as shown below I don't see git related modifications shown in the gutter nor does the commit history show up in the timeline view:

subst p: c:\Users\Byron\dev\projects\
code p:\project1

I can confirm this behaviour in VSCode 1.67.2 .. both native git gutters without any extensions installed, and with gitlens installed..

If you open the workspace file inside the subst drive, gutter annotations and modifications and file modification status won't show up. But if you open the same workspace file directly from the non-subst drive, then everything shows up and works as expected. Again, true for both native gutter display, and with gitlens installed.

I've also tried to make sure all the folders both subst and original have been trusted by workspace trust - to no avail.

Is there some reason why this does not work? Or some reason why it (seems like) will not be resolved after 6 years and numerous duplicate issues raised and closed? Maybe something in the manual/readme/known issues/wiki.. ?

[neilmunday]

+1 for getting this fixed!

[jwcclcraft]

Also confirming that it is behaving correctly on VSCode 1.67.2 for me.

edit: this is on Windows 10

[ispanos]

On Fedora 36:

code -v                
1.68.0
4af164ea3a06f701fe3e89a2bcbb421d2026b68f
x64

it is not fixed.

[TimofeyBiryukov]

On Windows 11 Pro (21H2) with wsl2 Ubuntu 20.04.4 LTS with VSCode 1.68.1
Creating a symlink in /mnt/c/User/... to a folder in ~.
The problem persists.