Vscode: Git: Support WSL

[tianvan]

[joaomoreno]

This was fast. The thing literally came out yesterday for everyone.

Actually, it's still not yet out, so support for this will take its time.

[johnbwoodruff]

It would be great to use Bash on Ubuntu on Windows as the integrated terminal! Not to mention its git installation for the git tab. I can't +1 this enough! :)

[johnbwoodruff]

Noticed that we can use the Bash on Ubuntu on Windows terminal in the integrated terminal now. That's awesome! Now we just need the git integration with the git version installed through bash on ubuntu on windows.

[dalyIsaac]

+1

[ncarroll]

+1

[nmbradford]

+1

[jonomacd]

This would be great not just for git but for extensions as well. I use the vscode-go extension and it shells out to use the command line tools often. I'd like it if it could shell out to bash as opposed to windows terminal. It would also need access to environment variables from bash. Basically, I want it to think it is in a bash environment even though it is in windows.

Thanks.

[ElieMyIdea]

+1

[andre2]

+1

[doxiaodong]

+1

[lobabob]

+1

[EmmanuelVlad]

+1

[kidpollo]

+1

[mikhailbalin]

+1

[lugolven]

+1 :)

[sgiradoa-psl]

+1

[skippednote]

@joaomoreno Wanted to check if there any work being done on this WSL git + VSCode integration?

[nickjj]

With Insider's 1.19 from Nov 15th I was able to track git commits with having VSCode installed on Windows while having git installed on WSL and do basically everything except pull/push (due to VSCode not using SSH keys from WSL) without any configuration or hacks.

But, with today's Nov 20th update now it's complaining about the git.path not finding a suitable version of git. However, it only checks Windows for a git installation instead of WSL.

Since this feature was working a few days ago, what should the new git.path be set to in order to integrate with WSL's git? i tried all sorts of bash.exe related paths without success.

[CoenraadS]

@nickjj Just set it to your Windows git.exe. VSCode never had support for WSL git. You can still use most of the features, but it will use the windows config not the WSL config.

[nickjj]

@CoenraadS I never had Git installed on Windows (ever).

Prior to this patch, the editor was capable of showing changes in a repo when git was only installed on WSL.

Is there a way I can roll back to Nov 15th's release?

[CoenraadS]

Prior to the latest insiders it checked the PATH, so if you do cmd -> where git.exe you might be surprised.

[nickjj]

where git.exe returns nothing from PowerShell, because I don't have Git installed on Windows.

If I run which git from WSL it's found at /usr/bin/git.

[CoenraadS]

I discovered this great project: https://github.com/andy-5/wslgit for people who want this support today.

ping @joaomoreno because maybe this would be an interesting route for VSCode team to think about.

[zaparo]

+1

[erend]

+1
Integrating this feature make web coding on Windows perfect.

[OmriSama]

+1

[seashore001x]

+1

[johnbwoodruff]

Hey everyone, friendly reminder to use the thumbs up reaction to the original comment instead of everyone posting +1. :) That's how interest is gauged, not by the number of comments with +1 which is harder to quantify. (Also doesn't spam everyone's notifications) ;)

[nikhilweee]

So with the new year, is there a native solution yet? Or is wslgit still the best workaround for now?

[mikerockett]

Looks like this hasn’t made it to the roadmap. :cry:

[trickymast3r]

Im workin in this !

[erikmueller]

Just a naïve approach: I tried installing Git for windows, then added the Program Files/Git/bin to my path and created an alias for git.exe=git (or you alias the exe directly)
Since WSL can run windows binaries both (wsl.exe/zsh and vscode integrated terminal) now use the windows git installation.
Maybe this helps and sorry if I got the problem wrong ^^

[pd93]

@erikmueller I believe this issue is for people who are using the WSL as their development environment and don't want to have to install Git for Windows in addition to WSL Git.

In other words, VSCode should be able to use WSL Git as it's SCM rather than requiring users to install additional software (Git for Windows).

It's worth noting that the integrated terminal can already use WSL Git, but that the SCM cannot.

[trickymast3r]

I'm done with this but ... VSCode so hard to commit my code ... sad !

I modify child_process to get into bash.exe and run git ...
convert every input path from win style to posix style.
convert every result path from posix style to win style.
Done ! git still working on my computer ... but i can't commit my work to repo ... i don't know why

[pd93]

@trickymast3r That's great news. Have you got a fork/PR everyone could take a look at?
If you're struggling to submit a PR, take a look at the vscode contribution guide

[jedmao]

@trickymast3r I had a similar thing going on in Node.js. I used pkg to package-up my git.js file into a git.exe file that ran a git.cmd file with the following contents:

@echo off
wsl git %*
@echo on

Vscode isn't complaining that Git doesn't exist now, but it is complaining that there are "no active source control providers."

I also tried mklink git.exe git.cmd. No 🎲🎲 !

[trusktr]

Can someone please take this out of Backlog? It's fairly relevant. Especially if you want to entice Linux/macOS devs to use Windows...

[Cifram]

Yes, was just struggling with this and am surprised to find it still not addressed. I'd really not have to maintain my ssh keys in two separate places with two installs of git. VS Code is great about working with WSL in so many ways, but this is still missing.

[hungryphilomath]

+1

[wasabigeek]

@Cifram I've gotten away with one set of SSH keys by creating one in /mnt/ and using it in both WSL and Windows - maybe that's an option to explore? This doesn't remove the need to install Git on both WSL and Windows though.

[MrBlenny]

I'm doing the same thing.
I gave wslgit but it was far too slow to be usable.

Instead installed GIT on windows as well as WSL.
Ssh keys are stored in wsl.
A symlink/junction was created in windows to link to wsl. Your path will vary.

mklink /J C:\Users\{User}\.ssh C:\Users\{User}\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\{user}\.ssh

I have heard that editing linux files from windows can cause problems so changes to these ssh keys should probably only be made from WSL.

[sudesh-poojari]

+1

[patrickxchong]

+1

[iksemot]

I've been looking into this and, I think, I made a little bit of progress. Maybe someone will be able to take this further.

The way it should work is to set "git.path": "wsl git" in User Settings of VSC as this is the preferred way of running WSL commands [1]. However there seem to be a problem with node child_process when spawning a command with spaces (needs confirmation).

The quite obvious solution, as already suggested [2], is to create a cmd script:

@echo on
wsl git %*
@echo off

and then use it in User Settings; "git.path": "C:\\wsl\\git.cmd".

However there is some problem with that. Turns out that spawning a process which starts wsl, for some reason makes child_process to wait for an input. And that prevents VSC to finish the process of locating git executable.

I monkey-patched resources\app\extensions\git\out\git.js function findSpecificGit to ignore stdin

options = {stdio: ['ignore', null, null]};
const child = cp.spawn(path, ['--version'], options);

And that made VSC to successfully recognize git! But now there's an issue with recognizing git repository.

What VSC does, it goes through various directories, starting with project directory and executes command wsl git rev-parse --show-toplevel which returns an absolute path to the git repository. But it returns it in Unix-lie format. And here I'm stuck.

[1] https://docs.microsoft.com/en-us/windows/wsl/interop#run-linux-tools-from-a-windows-command-line
[2] https://github.com/Microsoft/vscode/issues/9502#issuecomment-364043243

[pd93]

@iksemot Not sure if this is what you're looking for, but since Windows 10 17046 there is a tool called wslpath which will convert between windows/wsl paths. This will be included in the upcoming (April) release of Windows 10 (RS4).

This binary resides in the wsl bin, so perhaps something like this might work?
wsl wslpath -wa $(git rev-parse --show-toplevel)
That will convert the value returned by git to an absolute windows path.

[nikhilweee]

On the issue of child_process waiting for an input, does https://github.com/nodejs/node/issues/18431 seem to help?

[mikaturk]

So when are we getting a solution which is not a complete hack and just a setting?

[Audiosyncrasy]

👍

[kabala]

👍

[victor-perez]

What you can do is to first try wslpath and if that fails you try a normal git command. It's not ideal but it works.

See: Use WSL git inside VS Code from Windows 10 17046

UPDATED: as @mterrel already noticed the simple version was not able to add/stage files but more important also ls-tree was not working. This is because all of these commands are called with a absolute path. I've updated my version of the git.bat so it can handle calls with absolute paths

There is still one problem what is if you use a passphrase on you ssh for git it will not do any push, pull etc. from VS code. You will get a endless spinner because wsl will show Enter passphrase for /home/user/.ssh/id_rsa but this looks like a general problem of VS code with ssh and passphrase ( https://github.com/Microsoft/vscode/issues/13680 ) This is b.t.w. no problem if you add 'C:\Tools' to your PATH because you can then just enter the passphrase

[mterrel]

Updated: @victor-perez Your solution worked well for some things, but I wasn't able to add/stage files.

I created a new workaround that also converts paths from Win->WSL on the git command line. That enabled add/stage from VS Code. You can find that below. Comments/fixes appreciated!

Use WSL git with VS Code

[schankam]

2 years later, still no reliable option to do this simply with "git.path". Quite annoying...

[bardware]

Do you start code from wsl in the first place or do you start code from cmd?

[LynnScarlett]

sshkey please

[mroach]

What could be nice is an option to run all or select external binaries with WSL. For example if you're using code linters or runners they'll require things like Node (+ package bins), Ruby (+ gem bins), Elixir (+ package bins), PostgreSQL, etc. Currently the only way to get these working is installing them natively in Windows which is totally redundant and may not always produce the same results.

Currently the only practical way I can see around this is running a Linux VM with VS Code inside it.

[ameft]

@mroach there's a specific open issue about that: #22663. Let's add some pressure.. ;P

[tprasadtp]

I messed with some lines of Go and I could make it work with vs code. Its ugly hack and a lot of edge cases are not considered as well. Its here, for some reason vs code does not like buffered output, it looks ugly. Its not perfect but does the job for me anyway.

[zaparo]

@tprasadtp There is already a workaround: https://github.com/andy-5/wslgit

[hangxingliu]

I wrote a solution batch scripts project: https://github.com/hangxingliu/wslgit

It is inspired by a Rust project andy-5/wslgit. And you can use it by copy and paste without any compiler.

[grtrout]

@hangxingliu What benefit does your project have over andy-5's? Have you tested it to be faster?

[khuongduybui]

Andy's project was created before wslpath was published by wsl itself. Most of the logic was about path conversion. Now that wslpath is a provided tool, we don't really need to perform much logic or computation at all, so rust provides no benefits of significance. Meanwhile bash can be used anywhere without compiling or installing any additional dependencies. I think that's the main benefit.

[pd93]

@khuongduybui It's worth noting that the BASH solution does require gawk so technically does have a dependency.

Also, the Rust implementation does not require you to have the compile tools. You can simply use the exe downloaded from the releases page. The BASH solution actually requires you to place two files in two different locations; one in the WSL and one in Windows.

[khuongduybui]

I wouldn't say it's better. I was simply explaining why it's different. Whether a difference is considered better, worse, or irrelevant is entirely up to the environment it's applied in, so I won't argue with you.

[pd93]

@khuongduybui Agreed. and your point about performance still stands. I just thought I'd add some additional info.

[grtrout]

Thanks for the info. I cannot use Andy's solution since it makes git operations very slow on my machine (and prevents me from using tools like GitLens within VSCode). However, I can't use yours either since I am locked into an older Windows build that does not contain the native wslpath functionality. In any case, having two separate git installations, one in Windows and one in WSL/Ubuntu, seems to be generally working fine for me. So long that I point both Windows and WSL to the same git and maven local repositories (e.g., _/mnt/c/dev/git_ and _/mnt/c/dev/mvn_repo_), things appear to work. Perhaps I will run into a problem soon, though...using WSL is still rather new to me.

[pd93]

@grtrout I've been using separate installations for Windows and the WSL for around 6 months or so now and the only real issues I've come across are keeping the .gitconfig files and SSH keys synced.

I also have core.autocrlf set to input in both configs as this ensures that line endings are consistent no matter which version of Git I use.

While Andy's project works well for me, I still feel more comfortable using two official tools over a single unofficial one until VSC adds proper support. This is definitely down to the individual though.

[khuongduybui]

@grtrout I don't think wslpath is required for any of these "wslgit" solutions.

[grtrout]

@pd93 Great info - I will make that core.autocrlf change to prevent future headache. Regarding keeping SSH keys synced - without thinking much about it, I created one in WSL in addition to the Windows one I already had. I added both to my GitHub/GitLab profiles. Is there any reason it would make more sense to try syncing the same key across environments? If I misunderstood, let me know. Thanks.

@khuongduybui Thanks for the clarification. I made the assumption that wslpath was needed based on your comment:

Now that wslpath is a provided tool, we don't really need to perform much logic or computation at all, so rust provides no benefits of significance.

[haddigan]

@grtrout I have been using Andy's solution and although it is much slower than having a separate git installation, that hasn't been a non-starter for me, just a minor inconvenience. (I have tested ~@khuongduybui~ @hangxingliu 's solution as well and performing actions takes just about as long).

As @pd93 mentioned maintaining separate ssh keys and config across two different installations of git seems to be the main issue for most people. This is basically a situation where all the tools to make this happen are available, and it seems like a no-brainer as far as including it in an update. MS has provided all of these great tools to make development on Windows much better, but it just feels incomplete as long as those tools can't interoperate with one another.

[khuongduybui]

@grtrout I'm sorry for the confusion. I checked the code; none of them used wslpath.
@haddigan it's not MY solution. Creator is @hangxingliu

[hangxingliu]

Sorry for reply late, because I am on a business trip.

The reason why I created repository https://github.com/hangxingliu/wslgit (reference from https://github.com/andy-5/wslgit) are:

1. I am used to the Linux environment for develop, but I bought a LG gram laptop and it is hard to installed Ubuntu with ACPI. so I decided use Windows and WSL.
2. I don't want to maintain two sets of git config and SSH config between Windows and WSL. (and also problems about CRLF and Linux file permissions)
3. I have not learned Rust development. So It is hard to setup Rust environment and compile Andy's wslgit on Windows for me. (And Windows SmartScreen prevent me execute its pre-compiled binary file)
4. I chose bash to implement this repository because I am familiar with it, and you can use it very easy without compile. (And I will remove dependency gawk from repository because it can working well with awk and also gawk)

And I saw many people are discussing use wslpath instead of programmatic path conversion(using awk or Rust). But I think wslpath is hard to find which part of git output is the path that needs to be converted. And It is hard to decide which parameter for git is a path. (And wslpath will failed if its input parameter is not a valid path).

I also found a bug when converting path doesn't implement by wslpath: you changed mount point of Windows drive in /etc/wsl.conf. And I am thinking about how to resolve this problem.
And if anyone has good idea about this, I am very welcome discuss with you.

@grtrout @pd93 @khuongduybui

---

P.s. My most desirable solution is VSCode supports git in WSL.

[pd93]

@hangxingliu wslpath works absolutely fine with a custom mount point in the wsl.conf file. That's one of the advantages of using it. I've been using it like this for a while now.

Also, you can easily test if a command was successful or not by checking the error code. wslpath will return a non zero code if it fails. eg:

wslpath /bin
echo $?
# Output: 1

[sudesh-poojari]

@pd93 Can you share your setup or link on how to setup git using wslpath

[pd93]

@sudesh-poojari I should clarify. I am not currently using Git _with_ wslpath. I'm still using separate Git installations for Windows and WSL. However, I do sometimes use wslpath for other things.

There is an open issue for implementing wslpath into Andy's project, but there are a couple of blocking problems that need to be worked out. Take a look at the issue comments for details.

[hangxingliu]

@pd93 Thanks for your guide. I pushed a new commit in my repository. include fixed a bug about Windows batch file (escaped characters) and wslpath support for input parameters.

By the way, Do you have a good idea about convert linux path in git output to Windows path by using wslpath? Or maybe I need parser wsl.conf to resolve it?

[pd93]

@hangxingliu the -w flag will convert from a WSL formatted path to a Windows one. eg:

# Windows -> WSL
wslpath C:\\Users\\Pete
# Output: /mnt/c/Users/Pete

# WSL -> Windows
wslpath -w /mnt/c/Users/Pete
# Output: C:\Users\Pete

You can also ensure that you get an absolute path by parsing the -a flag
wslpath still works for the above example even if your mount point is / instead of /mnt (like mine is)

[hangxingliu]

@pd93 That's right. Sometimes the output of git is only a path string, for example:

> git rev-parse --show-toplevel
/mnt/c/repo1

But there are some conditions: the output of git is not only a path string, also many other description text .and maybe includes more than one path, for example:

> git remote -v
local   /mnt/c/local_remote (fetch)
local   /mnt/c/local_remote (push)
origin  [email protected]:hangxingliu/wslgit.git (fetch)
origin  [email protected]:hangxingliu/wslgit.git (push)

So It is hard to extract which part is a Linux path be mounted from Windows drive by using wslpath only in the second condition(The output included more than one path or included other strings)

[hangxingliu]

@pd93 Up to latest commit in my wslgit repository. It supported convert Linux path in git output to Windows path by wslpath or awk (replace path following WSL mounted drvfs list).

[andy-5]

For anyone having performance issues with wslgit or similar tools, the slowdown is most likely caused by the execution of your Bash startup scripts (like .bashrc).

For andy-s/wslgit specifically, you can force it to not start an interactive Bash shell, which skips executing .bashrc, by setting the Windows environment variable WSLGIT_USE_INTERACTIVE_SHELL to false (as documented here). This can significantly speed up wslgit, but does not run any tools like ssh-agent, etc. you may have added to your .bashrc.

[mickeypuri]

Discussing with a colleague, he has simply set in vscode user preferences, the terminal.integrated.shell.windows to point to the bash.exe for WSL, and then set git.path in vscode preferences to the path in the WSL where git is installed e.g.

"terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe",
"git.path": "C:\\Users\\some_user_name\\AppData\\Local\\lxss\rootfs\\usr\\bin\\git",

It appears to work however he is not using the vscode git plugin as it felt flaky. Is this a potential solution or is something being missed in this setup (as I know we are not meant to alter any files in the linux system using any windows tools)?

(One point on the git.path, more recent installs of bash, will use a different path rather than the lxss folder as outlined here )

[haddigan]

@mickeypuri I just tried this and VSCode is unable to find the source provider. What is it that appears to work if your colleague isn't using the source control integration? I'm not sure what setting git.path would accomplish otherwise. You can definitely point the integrated shell to WSL and run git from the command line, but this issue is for being able to use the Source Control integration with WSL's git.

[galcianuk]

Would also like support for this!

[nzec]

Can anyone take a look at this Gist by @victor-perez : https://gist.github.com/victor-perez/8ba25540394ec68b11f4b2699fb4d4ce

It doesn't work for me. Can anyone else test it out?

[nzec]

Figured it out by using this : https://github.com/andy-5/wslgit

[mike-zipit]

This is working for me: https://gist.github.com/victor-perez/8ba25540394ec68b11f4b2699fb4d4ce

[phifa]

@joaomoreno Integrating WSL GIT into VS Code would be amazing! Any updates here?

[mmirus]

@phifa I've been using it in VS Code for quite a while. IIRC all you need to do is save the latest wslgit.exe release to your computer and then tell VS Code to use it in your settings:

"git.path": "C:\\tools\\wslgit.exe",

[murillopaula]

@mmirus Yes, but we want to use this feature without downloading or installing anything on Windows other than WSL itself.

[nickjj]

Keep in mind if you go with the wslgit.exe approach, it works but it's deadly slow. So slow that it's completely unusable (even when things outside of Git was very fast).

[phifa]

@joaomoreno is a native integration in VSC planned?

[ruhulamindev]

It's 2019.. It's been about 3 years since this issue was brought up... We see no progress at all.

Git with vscode is the only reason I am in linux.. using wsl and git for windows together causes some crazy problems like losing permissions on some folders/files. So please vscode guys do something.

[mmirus]

I know it's not a permanent solution but if you haven't tried wslgit with vscode, give it a shot. It's stable and performs quite well for me.

[phifa]

Well I think a heads up would be good. Is it being worked on? Can we contribute or test? Don’t leave us in the dark 🙂

[pd93]

@phifa I think @mmirus is referring to https://github.com/andy-5/wslgit which is an unofficial workaround.

Edit: Some have reported that it's quite slow compared to using Git for Windows, so I still prefer to have both Git for Windows and WSL installed. Only downside is that I have to ensure my SSH keys and .gitconfig are replicated.

Would obviously prefer to stop using Git for Windows though!

[benc-uk]

wslgit is slow as hell and it's a cludgy workaround.

Also SCM/git is just one part of the WSL integration we need from VSCode

[ChristianGrimberg]

Figured it out by using this : https://github.com/andy-5/wslgit
Works great for me :+1:

WSL & Git & Visual Studio Code without Git Bash

[phifa]

@joaomoreno any updates on this?

[llatseattle]

Any update on this?

[andreialecu]

wslgit is not slow at all in my experience if set up properly.

Just remember to set the WSLGIT_USE_INTERACTIVE_SHELL variable in Windows to false, see the documentation in its README.

[panoscool]

the integrated terminal is working fine with the wsl the issue is the vscode git sidebar is not working at all with the wsl

[quhung1989]

@panoscool This is what I did to resolve the side bar issue. I opened "Git Bash" in Windows and and ran:

git config --global core.excludesfile '/the/absolute/path/to/your/global/git/ignore'

So currently Git Bash and WSL are referencing the same ignore file globally. I was not sure how Git Bash handles absolute paths so I did "cd ~" and "$PWD" and it returned "/c/Users/username".

[RMacfarlane]

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

[xty]

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

@RMacfarlane Thank you for the heads-up. It really looks great! I have one question though:
Now with the Visual Studio Code Remote - WSL extension in action, will VS Code automatically pick up the Git installation in WSL or do we have to manually configure "git.path" in the WSL specific settings?

Update [2019/05/03]: Upon investigation, it appears Git installation in WSL is picked up automatically. This is awesome🎉!

[benc-uk]

It automatically finds git from the WSL system path, no need to configure anything

[12101111]

With remote-wsl extension, vscode will use toolchains in wsl, but sometimes we just want to use git in wsl and continue to use the toolchain in Windows.

[andreialecu]

One probably helpful piece of information regarding the new Remote - WSL extension, which I needed to do in my project:

If you open your folder from the windows path, like you used to - such as from your recent projects menu, the extension won't kick in - everything will still be in Windows mode.

What I had to do was to use Remote-WSL: Open Window, then the File > Open Folder... menu will show you Linux paths, so you need to browse for your folder from there (/mnt/...) and open that instead.

After doing this the git used by Code will be the native one from WSL, and your terminal windows will also use bash by default.

[panoscool]

@andreialecu if you open the project from wsl terminal using code . wsl Git is working right?

[andreialecu]

@panoscool code-insiders . doesn't seem to work properly from the WSL terminal. It still opens via the Windows path, meaning the extension doesn't kick in - so you don't get WSL Git or any other WSL capabilities.

It also prints an error to the console, which code . doesn't:

 $ code-insiders . 
/c/Users/<snip>/AppData/Local/Programs/Microsoft VS Code Insiders/bin/code-insiders: line 29: cmd.exe: command not found

Opened #73330

EDIT: Actually, it does work if you have /c/Windows/System32 in your PATH (which would be there by default), but I disabled Windows path propagation into WSL. I posted a workaround in the issue opened above.

[andreialecu]

My experience after a few days with Remote-WSL (valid May 2019):

I went back to using wslgit on stable Code. While Remote-WSL is extremely promising, I kept running into file system issues, such as various EACCES errors, and even hard lockups because of the NTFS<->WSL file access issues and VS Code was exacerbating them as well.

One example (using React Native) was weird lockups of the Android emulator in Android Studio that could only be resolved by a computer reboot. Additionally, Android Studio would rarely build the project without complaining about being unable to replace some file because of access denied issues. Had to randomly close/reopen Code to try to get past these errors.

One other annoying thing for example is that you are unable to rename a directory after opening it via Remote-WSL. It's a known limitation, among others listed here: https://code.visualstudio.com/docs/remote/wsl#_common-limitations-in-wsl

These will all likely be resolved once WSL 2.0, which was just announced, goes live. It should hit the Windows Insider channel in late June: https://devblogs.microsoft.com/commandline/announcing-wsl-2/

In the mean time, wslgit, while it has its quirks, is currently less of a hindrance to work with.

[aeschli]

Thanks for the feedback, @andreialecu. Yes, the fs locking issues are nasty. As you said, they will only go away with the VM2 mode. In some cases you can work around the issue by defining watcher excludes ('files.watcherExclude") for folders where other tools work (e.g. node_modules...)

For the cmd issue you created https://github.com/microsoft/vscode-remote-release/issues/170, thanks!