microsoft / vscode

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

Git: Support WSL #9502

Closed tianvan closed 5 years ago

tianvan commented 8 years ago

qq 20160720033734

mterrel commented 6 years ago

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

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

bardware commented 6 years ago

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

LynnScarlett commented 6 years ago

sshkey please

mroach commented 6 years ago

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

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

tprasadtp commented 6 years ago

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.

refparo commented 6 years ago

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

hangxingliu commented 6 years ago

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

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

khuongduybui commented 6 years ago

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

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

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

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

grtrout commented 6 years ago

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/mvnrepo), things appear to work. Perhaps I will run into a problem soon, though...using WSL is still rather new to me.

pd93 commented 6 years ago

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

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

grtrout commented 6 years ago

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

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

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

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

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

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

pd93 commented 6 years ago

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

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

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

@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  git@github.com:hangxingliu/wslgit.git (fetch)
origin  git@github.com: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 commented 6 years ago

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

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

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

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

Would also like support for this!

nzec commented 6 years ago

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

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

mike-zipit commented 5 years ago

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

phifa commented 5 years ago

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

mmirus commented 5 years ago

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

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

nickjj commented 5 years ago

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

@joaomoreno is a native integration in VSC planned?

developerruhul commented 5 years ago

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

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

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

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

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

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

@joaomoreno any updates on this?

llatseattle commented 5 years ago

Any update on this?

andreialecu commented 5 years ago

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

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