Closed marcelkornblum closed 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
?
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.
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!
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 :(
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.
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...
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.
I have Ubuntu WSL installed from the store and WSLGit running as
git.exe
, with thegit.path
pointing to it correctly. I just switched my config to use an SSH key with no passphrase, and setWSLGIT_USE_INTERACTIVE
to0
in my environment settings.Running the git.exe executable under
bash
works fine. TheOutput > 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 displayingNo source providers registered
, which is what it settles on.I'm aware this may be more a
vscode
issue than awslgit
one, but given the unusual setup I thought I'd try here first.Any ideas?
Here's the Git Output: