Closed tianvan closed 5 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!
2 years later, still no reliable option to do this simply with "git.path". Quite annoying...
Do you start code
from wsl
in the first place or do you start code from cmd
?
sshkey please
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.
@mroach there's a specific open issue about that: #22663. Let's add some pressure.. ;P
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.
@tprasadtp There is already a workaround: https://github.com/andy-5/wslgit
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.
@hangxingliu What benefit does your project have over andy-5's? Have you tested it to be faster?
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.
@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.
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.
@khuongduybui Agreed. and your point about performance still stands. I just thought I'd add some additional info.
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.
@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.
@grtrout I don't think wslpath is required for any of these "wslgit" solutions.
@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.
@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.
@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
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:
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.
@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
@pd93 Can you share your setup or link on how to setup git using wslpath
@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.
@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?
@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)
@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)
@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).
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
.
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 )
@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.
Would also like support for this!
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?
Figured it out by using this : https://github.com/andy-5/wslgit
This is working for me: https://gist.github.com/victor-perez/8ba25540394ec68b11f4b2699fb4d4ce
@joaomoreno Integrating WSL GIT into VS Code would be amazing! Any updates here?
@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",
@mmirus Yes, but we want to use this feature without downloading or installing anything on Windows other than WSL itself.
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).
@joaomoreno is a native integration in VSC planned?
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.
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.
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 🙂
@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!
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
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
@joaomoreno any updates on this?
Any update on this?
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.
the integrated terminal is working fine with the wsl the issue is the vscode git sidebar is not working at all with the wsl