Git: Support opening repositories on symlinked paths

[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.

[cmsax]

Still not fixed... git gutter indicator not shown in remote development via ssh.

[wmmc88]

I'm still encountering issues with this on W11 + VS Insiders + having a directory junction in the path. The Source Control tab correctly detects changes, but the File Explorer tab + the gutter indications are both not functional. Is someone on the vscode team working to address this issue?

[th1nk3r-ing]

I'm still encountering issues with this on W11 + VS Insiders + having a directory junction in the path. The Source Control tab correctly detects changes, but the File Explorer tab + the gutter indications are both not functional. Is someone on the vscode team working to address this issue?

Windows 10 using vscode on WSL1 still has this bug

[frankli0324]

the root cause I believe is quite clear:

vscode git extension uses the command git rev-parse --show-toplevel to find the repo roots:

main/extensions/git/src/git.ts#L481-L484

however, when in cases where repo is located at a linked path, git returns the realpath instead.

forwarded from the issue I opened.

so I propose git rev-parse --path-format=relative --show-toplevel instead of just --show-toplevel

[YijiangPang]

VSCode Version: 1.79.2 (Universal)
OS Version: macOS 13.4 (22F66)
remote OS: Ubuntu 22.04.2 LTS (through extension remote-ssh v0.102.0)

the bug still exists where the changes cannot be tracked by git if the project fold is a soft link.

[lszomoru]

@frankli0324, thank you very much for pointing out the --path-format flag that was added in git 2.31.

Todays VS Code Insiders release (v1.81) contains code changes to better handle repositories that have symbolic links on their path. I have confirmed that 1) diff decorations in the editor as working as expected, 2) resources in the "Source Control" view are opened correctly. The only known issue that I am tracking is that there are cases in which the same repository is duplicated, which I am looking to address early next week.

It would be great if people using symbolic links would download and install the latest VS Code Insiders release, upgrade to git 2.31 and try things out so that we can find some of the issues that are still present that I might have missed. Thank you very much for your help and apologies that it took so long to get this addressed

[Migelo]

Works for me! ❤️

[lszomoru]

The only known issue that I am tracking is that there are cases in which the same repository is duplicated, which I am looking to address early next week.

Today's Insiders release (2022-07-11) contains the fix so the issues mentioned above. Let me know if you still see any issues.

[lszomoru]

Given the positive feedback and no new issues reported I will go ahead and close this issue as resolved. In case any of you find any issues with the symbolic link support please file a separate issue and mention this one for reference. Thank you!

[brando90]

@lszomoru I'm having a similar issue. The issue is due to the permission for microsoft/vscode-remote-release#8731 outlined there.

[brando90]

Ok the issue seems to be particular to my cluster that is set up in a ridiculous fashion. There is a odd token kerberos thing that they over manage (mentioned here https://unix.stackexchange.com/questions/724685/how-does-one-authenticate-with-a-command-that-requires-your-password-in-linux) anyway once I run reauth it works. So make sure your permissions are right, for me it was through by getting the token again. The symlinks refreshed by themselvers.

soln: https://stackoverflow.com/questions/76725830/how-to-make-explorer-in-remote-shh-extension-in-visual-studio-code-vscode-do/76732251#76732251