search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.61k stars 29.03k forks source link

Git: Support WSL #9502

Closed tianvan closed 5 years ago

tianvan commented 8 years ago

qq 20160720033734

quhung1989 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

12101111 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

andreialecu commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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!