Vscode: 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.

[hyperfekt]

Staging ranges of a file opened through a symlink is broken as well, and will lead to weird behavior where instead the file that is the symlink has the selected range staged and every other line from the target is displayed as changes in the symlink file in the git side bar.

[ryansully]

This issue, specifically git gutters not displaying but maybe others as well, also occurs for remote symlinked git repos using the Remote - SSH extension.

[UnicodeTreason]

Can confirm, no Git gutter's when using a symlinked path in Remote WSL (Though other Git features seem to work fine)
But if I navigate to the same path using /mnt/c and start up "code ." it all works fine.

[seanknox]

is the issue with the Remote SSH extension (and thus bugs/work should be tracked there) or with vscode itself?

[dulinux]

Same issue here when working on a linked folder. If a open the target folder, it works. If a open the symbolic link 'folder', gutter annotations won´t work.

[Throne3d]

Is there a way to recognize this from the extension, and perhaps provide an error in some log (like the VSCode "Show Git Output" log)? I don't know the internals work of these extensions work, but it took me a lot of Googling to find this error – the keyword I was missing was "gutter".

[dileepkr]

I am facing the same issue when using RemoteSSH for VSCode. Git gutter works on files with full path but doesn't work on same when opened with relative path.

Is there a solution for this problem?

[AddictArts]

Open the non-symlinked path worked for me, but I had the same issue Feb 26, 2020.

[AddisonG]

Yeah, this is pretty terrible. I've used all sorts of other OS-level hacks to get around this issue.

[tungel]

Yeah, this is pretty terrible. I've used all sorts of other OS-level hacks to get around this issue.

Do you mind sharing what you did to work around the issue?

[AddictArts]

I navigated directly through /mnt/c/... I had the project symlinked from $HOME/project. Just needed to use an absolute path from root.

[molinav]

I have a very similar issue, a $HOME folder built on login as symlink to a folder in /mnt/home. If I open my project with the path containing $HOME, all the Git decorations are missing. If I open the same project with the real path that uses /mnt/home, then the Git decorations appear as normally.

[arnauldvm]

The issue also impacts the "Timeline" view introduced with the March Upgrade.

→ Opening a project through a symlink: no git decorations, timeline view empty

→ Opening a project through "actual" path: all git decorations, timeline view filled with git history

[TimofeyBiryukov]

Getting the same issue. Using remote wsl. Can't use /mnt/* to store any of the project files due to the https://github.com/microsoft/WSL/issues/4197 and running code . from symlink in /mnt/* will lead to this.

[qguv]

Not much discussion here, but it looks like a lot of people are having the same issue with git integration breaking when symlinks are involved, see #94851, #89464, #82873, microsoft/vscode-remote-release#309, #60010, #57580. Is there any plan to work on fixing this issue?

I don't think the "feature request" label is appropriate here; this appears to be a bug, since the underlying tool (git) doesn't seem to have trouble dealing with symlinks.

[cotneit]

In case someone needs a workaround:

function codeSymlinks() {
  if [[ -e "$1" ]]; 
  then
    code "$(realpath $1)" "${@:2}"
  else
    code "$@"
  fi
}

alias code='codeSymlinks'

Explanation:
if directory or file exists, its absolute path will be passed to VS code alongside with other parameters;
if directory or file doesn't exist, all the arguments will just be passed to VS code
Usage: just add it to your .bashrc or .zshrc

Works fine for me, feel free to tweak it if you find any issues

Edit: Got excited there for a moment, it still doesn't seem to change status in the sidebar

[PrzemyslawKlys]

I've just been told my issue with git 2.28 is because of this 4-year-old issue. I use symlinks on Windows. The thing is - it works fine when I'm using Git 2.23. So you may want to try Git 2.23 (originally reported my issue here: https://github.com/microsoft/vscode/issues/103798)

I link the whole folder from C drive to OneDrive.

You can try 2.23, maybe it will work for you?

[YuvalFatael]

Experiencing the same issue (using git 2.23.3), my entire homedir is a symlink. When accessing the workspace with the realpath everything works normally.

[neilpalima]

I am using WSL2 and encountered this issue. I hope this will be fixed soon.

[xploSEoF]

4 years of this being an issue - I guess it's low priority. Unfortuantely, most of us who use WSL find /mnt/c/projects/folder, or worse /mnt/c/Users/username/projects/folder to be way too long and operate on a /p/folder kind of basis for our main projects via a symlink.

[MrHedmad]

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