andy-5 / wslgit

Use Git installed in Bash on Windows/Windows Subsystem for Linux (WSL) from Windows and Visual Studio Code (VSCode)
MIT License
1.18k stars 59 forks source link

WSLGit works, does not work in VSCode #60

Closed marcelkornblum closed 5 years ago

marcelkornblum commented 5 years ago

I have Ubuntu WSL installed from the store and WSLGit running as git.exe, with the git.path pointing to it correctly. I just switched my config to use an SSH key with no passphrase, and set WSLGIT_USE_INTERACTIVE to 0 in my environment settings.

Running the git.exe executable under bash works fine. The Output > Git menu in VSCode shows that it finds the right executable, and can run it (output below).

The issue is that every time I open or switch to a file under version control the SOURCE CONTROL pane flickers between showing the 'calculating changes' interfaces and displaying No source providers registered, which is what it settles on.

I'm aware this may be more a vscode issue than a wslgit one, but given the unusual setup I thought I'd try here first.

Any ideas?

Here's the Git Output:

Looking for git in: C:\Users\MarcelKornblum\Projects\git.exe
Using git 2.17.1 from C:\Users\MarcelKornblum\Projects\git.exe
> git rev-parse --show-toplevel
> git config --get commit.template
Open repository: \c\Users\MarcelKornblum\Projects\website
> git status -z -u
> git rev-parse --show-toplevel
> git config --get commit.template
Open repository: \c\Users\MarcelKornblum\Projects\netlify-cms-oauth-provider-python
> git status -z -u
> git rev-parse --show-toplevel
> git config --get commit.template
Open repository: \c\Users\MarcelKornblum\Projects\website
> git status -z -u
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git config --get commit.template
Open repository: \c\Users\MarcelKornblum\Projects\website
> git status -z -u
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git config --get commit.template
Open repository: \c\Users\MarcelKornblum\Projects\website
> git status -z -u
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git config --get commit.template
...
Open repository: \c\Users\MarcelKornblum\Projects\website
> git status -z -u
> git rev-parse --show-toplevel
> git config --get commit.template
andy-5 commented 5 years ago

The paths in the "Open repository..." lines do not look right.

Can you please check the output of C:\Users\MarcelKornblum\Projects\git.exe rev-parse --show-toplevel by running it from a command prompt within a git repository? It should print a path like c:\Users\....

Do you have any special mount points setup inside WSL, or configured custom mounts in wsl.conf?

marcelkornblum commented 5 years ago

The output from that command (run from within a repo called website, navigated to via cmd is the same (other than slash direction) as the "Open repository" line:

/c/Users/MarcelKornblum/Projects/website

I don't think I've set up any custom mounts though this is my first Windows machine in a long time and it's possible I did something following a tutorial online while trying to set up. There's no files at /etc/wsl.conf in any case.

ottobricks commented 5 years ago

Hi there, Andy.

First of all, kudos to you for tackling the wls, git and vscode issue (which really MS should have solved by now). Having said that, I'm running into the same issue as @marcelkornblum. Are there any news on how to solve it?

Thank you in advance!

marcelkornblum commented 5 years ago

It turned out I had something in .bashrc from trying to run docker in wsl. I managed to get it running with trial and error by fiddling with settings and looking at the git output panel until it matched what Andy was expecting. Unfortunately I can't have docker mounting working at the same time as it seems it needs the exact opposite setting :(

andy-5 commented 5 years ago

Yes, exactly. Currently, wslgit only supports the default WSL mount points under /mnt, while Docker needs everything mounted directly under /. I have some plans to support more general mounts, but no concrete implementation yet.

marcelkornblum commented 5 years ago

It feels as though both ought to be able to be working at the same time, but I tried symlinks and new mount points and all sorts of ideas without luck. I guess really this issue should be closed, but do you know if there's something I can subscribe to for when you figure it out @andy-5 ? If there's anything I can do to help of course please let me know, the work you've done to date is great...

andy-5 commented 5 years ago

You mentioned that you setup the mounts for docker in .bashrc - are you using something like sudo mount --bind /mnt/c /c there? Because there seems to be a workaround for that specific setup, see https://github.com/andy-5/wslgit/issues/33#issuecomment-412774712.

If you set the Windows environment variable WSLGIT_USE_INTERACTIVE_SHELL to 0, .bashrc should not be executed when running wslgit, so the default mount points are used and everything works fine. However, once you open a WSL shell, which executes .bashrc, the mount points are changed permanently (until the next reboot) to the way docker expects them.

The workaround is to open your project in VS Code before opening any WSL shell. wslgit should work correctly then, and VS Code internally remembers the correct path to the repository. Afterwards, you can open a WSL shell, which changes the mount points. From then on, wslgit will not correctly translate the paths anymore, but most commands should work fine from within VS Code (because it remembered the correct path to the repository).

For a proper fix, you can follow issues #12 and #42 (which describes the same problem, but with a different setup). As you suggested, I'm closing this issue now in favor of the others. Feel free to share any updates on your specific setup or possible workarounds you may find.