Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Git: Symlink support #5970

Open
mrded opened this issue Apr 29, 2016 · 48 comments
Open

Git: Symlink support #5970

mrded opened this issue Apr 29, 2016 · 48 comments
Assignees
Labels
feature-request git
Milestone

Comments

@mrded
Copy link

@mrded mrded commented Apr 29, 2016

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

@joaomoreno joaomoreno added bug git labels Apr 29, 2016
@jeremyjjbrown
Copy link

@jeremyjjbrown jeremyjjbrown commented Jun 2, 2016

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

@joaomoreno joaomoreno added this to the Backlog milestone Jun 3, 2016
@mightypenguin
Copy link

@mightypenguin mightypenguin commented Sep 14, 2016

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
Copy link
Member

@joaomoreno joaomoreno commented Sep 14, 2016

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.

@joaomoreno joaomoreno changed the title Problems with adding symlinks to git repository Can't open symlinks from git viewlet Sep 14, 2016
@mightypenguin
Copy link

@mightypenguin mightypenguin commented Sep 15, 2016

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
Copy link
Member

@joaomoreno joaomoreno commented Sep 15, 2016

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

@mightypenguin
Copy link

@mightypenguin mightypenguin commented Sep 15, 2016

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
Copy link
Member

@joaomoreno joaomoreno commented Sep 17, 2018

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

@joaomoreno
Copy link
Member

@joaomoreno joaomoreno commented Sep 18, 2018

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

@NightMachinery
Copy link

@NightMachinery NightMachinery commented Feb 28, 2021

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

@wscnd
Copy link

@wscnd wscnd commented May 5, 2021

@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
Copy link

@martindale martindale commented May 5, 2021

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
Copy link

@dragonly dragonly commented May 26, 2021

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
Copy link

@excelsi0r excelsi0r commented Jun 30, 2021

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
Copy link

@Migelo Migelo commented Jun 30, 2021

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
Copy link

@adekmaulana adekmaulana commented Jul 5, 2021

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

@macsz
Copy link

@macsz macsz commented Oct 1, 2021

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.

image

@lszomoru lszomoru self-assigned this Oct 4, 2021
@fsievers
Copy link

@fsievers fsievers commented Dec 6, 2021

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
Copy link

@AlexHarn AlexHarn commented Jan 3, 2022

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
Copy link

@wcheek wcheek commented Jan 17, 2022

Agreed. This needs to get fixed.

@samarth-robo
Copy link

@samarth-robo samarth-robo commented Jan 23, 2022

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

@marcitqualab
Copy link

@marcitqualab marcitqualab commented Apr 6, 2022

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
Copy link

@byerun byerun commented May 14, 2022

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
Copy link

@starfishpatkhoo starfishpatkhoo commented May 27, 2022

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

Noprop added a commit to Noprop/vscode that referenced this issue Jun 1, 2022
@neilmunday
Copy link

@neilmunday neilmunday commented Jun 1, 2022

+1 for getting this fixed!

@jwcclcraft
Copy link

@jwcclcraft jwcclcraft commented Jun 9, 2022

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

edit: this is on Windows 10

@ispanos
Copy link

@ispanos ispanos commented Jun 12, 2022

On Fedora 36:

code -v                
1.68.0
4af164ea3a06f701fe3e89a2bcbb421d2026b68f
x64

it is not fixed.

@TimofeyBiryukov
Copy link

@TimofeyBiryukov TimofeyBiryukov commented Jun 25, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request git
Projects
None yet
Development

No branches or pull requests