GIT repository not detected in VSCode Source Control

[paulklemm]

I've successfully mounted a remote folder with the plugin. It contains a GIT controlled project. VSCode however does not detect it as such. Is this intended behavior?

[UnicodeTreason]

Replicated behaviour on a Windows system.

Workspace local on my PC, git features work fine.
Workspace via SSH FS, source control provider not detected as active.

[giulianovelli]

Same for me on Mac OS, git works fine locally but source control provider not detected within the SSH FS Workspace.

[SchoofsKelvin]

It doesn't seem like I can (easily) add support for this right now. My hope is that once I implement some other features, most noticeably the SearchProvider, vscode will recognize the git repositories again.

Since the Git Output shows it is running git rev-parse --show-toplevel, I'm not sure whether that'll actually work.

[brentashley]

The issue seems to be that the SSHFS workspace root looks like "/" to vscode (hover over the folders in workspace to see their path) so when vscode passes the directory / to the external git command, git looks in "C:/" for repositories. Possibly if the SSHFS filesystem was mounted to a driveletter (say, R:), the external git command could find the .git files in R:/. On non-win machines, a full mount path could do it.

[brentashley]

Apart from the git issue, this could potentially affect any vscode feature or extension that uses the file path. for instance if I were to use a plugin that modifies a file and apply it to a file in my workspace called /etc/hosts I could end up overwriting my workstation's /etc/hosts file.

[SchoofsKelvin]

I just handled another issue (#42) related to extensions not supporting remote files. The problem is that with git, the git.exe can't access ssh:// URLs, as those are provided by the extension within vscode.

There are some extensions created before the FileSystemProvider API got added that actually write the files to the local disk, and just upload them when they're modified. For now, it's just waiting for existing extensions to make use of the new API, instead of directly reading/writing from/to disk.

[brentashley]

Thanks for the info. I guess we will likely have to wait until support for ssh:// URLs gets into the builtin git integration. I can't see third parties being too motivated to write git support extensions when it's built in.

[paulklemm]

Are there any open issues on this that we can support to speed up the process?

[SchoofsKelvin]

There doesn't seem to be an issue about this on the vscode GitHub, although it might've been mentioned in related issues.

[paulklemm]

Ok I guess we'll put this on ice for now since there is not much we can do about it.

[floatingpurr]

Same problem here. I was wondering if the problem remarked by @brentashley can have any serious drawback also on macOS.

[WSLUser]

See the linked issues.

[osterik]

Workaround: use new feature called "Visual Studio Code Remote Development Extension Pack"

We just announced remote development with VS Code, check out the blog post for details https://code.visualstudio.com/blogs/2019/05/02/remote-development

via

[sergei3000]

@osterik this is not a workaround for many people because it requires to open connection to some Microsoft's websites from the remote server, which is not possible on many corporate servers.

[csaska]

If you folks still want this support, I suggest you go like the new issue I opened.

microsoft/vscode#109954

[mitchelangelo]

SSH FS is a useful plugin, a work around involving caching the target directory locally and restoring source control features would be ideal. That way you don't have to overcome the permission issue, you could add a hook to save which saves both locally to the cached repo and remotely to the source for synchronization. You would also have to include hidden files to keep both repos in sync. That could be a possible work around for SSH FS to restore source control feature of remote git repositories for targetted directories which open a workspace.