Open repository in WSL filesystem (\\wsl$\...)

[carlolars]

Open a repository in the WSL filesystem using the UNC path (\\wsl$\Ubuntu-18.04\tmp\gittest) is not working since Forks directory browser can't handle such path. But if adding the repository manually to settings.json in AppData\Local\Fork then it works in Fork (at least when using wslgit as custom git-client).

Would be really neat if this could be added, mainly because of WSL2 where the file access from within WSL2 to Windows file system is supposedly slower.

Originally posted by @carlolars in https://github.com/ForkIssues/TrackerWin/issues/608#issuecomment-575342549

[carlolars]

Browsing \\wsl$\ actually works for me now when using WSL2. I assume it is WSL2 that is making it work and not the upgrade to Ubuntu-20.04...

[spaceemotion]

While I've had no problems with WSL2 and Fork so far, the performance has been quite slow. I suspect this is due to the native git installation on windows trying to read the data over the network share. Would love to see Fork use the git instance inside the WSL machine instead!

[Stanzilla]

Agree, JetBrains recently added support for that in WebStorm so it is possible: https://www.jetbrains.com/webstorm/whatsnew/

[carlolars]

Would love to see Fork use the git instance inside the WSL machine instead!

Until that happens you can always try out wslgit 😉.
Version 1.0.0 was just released which makes the integration with Fork much easier.

[spaceemotion]

Thanks for the tip! Still feels a bit slower than usual (albeit faster than through the bundled version).

Edit: Seems like I've spoken too soon - I am unable to fetch or push changes, it just hangs....

[yisyang]

Just tried wslgit on Fork and everything's been working well, even the symlinks!

OS: Win 10 WSL2: Ubuntu 20.04

For some strange reason performance was never an issue with Fork even before using WSL git. I've also tried using runnings other GUI git clients inside of WSL2 and forwarding display to VcXsrv and that works too.

[DanPristupov]

I made a test build with basic WSL2 support. Can you try and tell if it is any faster for you?

You can download the build here: https://cdn.fork.dev/prerelease/Fork-1.57.15.zip. Just extract the archive and run fork.exe. Then try to open any repository in '\wsl$\'.

This is a test build and rebase and remote operations (fetch/push) don't work. However you must be able to see if it's faster or not.

[Stanzilla]

That's quite a bit faster indeed

[joostmeijles]

Does Fork work out-of-the-box with WSL2 (and \\wsl$\... paths) now?

[Stanzilla]

Not yet, no. It uses Git for Windows which has problems with UNC paths for config loading and also is pretty slow on the wSL share.

[joostmeijles]

Ah that's unfortunate. Is there a workaround for it? I tried wslgit but Fork does not detect the Git repo when I use it.

[DanPristupov]

I made a build of Fork 1.62 (the latest) with the included WSL support

WSL repos are identified by \wsl$ path root then the wsl git instance will be used. Some people have been working with this build in production for quite a long time and gave me a positive feedback.

A list of things which must work properly now:

• Remote operations (fetch, pull, push, clone, test connection etc), both HTTPS and SSH
• Interactive Rebase
• ZSH
• Commit and creating tags
• Submodules

Could you try and check if it works for you? If everything is stable, we can start merging it into the official release.

https://cdn.fork.dev/prerelease/ForkWin-1.62.2-wsl-1.zip

[Stanzilla]

Is there anything I have to do or does it just use the WSL git automagically no matter which Git version is selected in the settings?

Okay looks like automatically because this is super fast, oh man.

[DanPristupov]

@Stanzilla It should work automatically. We should probably add some icon or sign when repo is opened in WSL mode.

[Stanzilla]

Yep makes sense, then maybe also add an option for the "Open in VSCode" to use WSL mode as well. Really love this! The performance is great and I haven't had any issues so far. Have not tested tagging and interactive rebase yet.

[carlolars]

Nice work, I'll try it as my daily driver.

Just to confirm, the .gitconfig and .ssh configs are from the Windows home folder and not the WSL home folder? And the 'ssh' binary used is from WSL?

[DanPristupov]

@carlolars both .gitconfig and .ssh configs are be from the WSL instance.

However, if you override the ssh config in the SSH configuration dialog, the selected key will be used instead. So, make sure, no keys are selected in that dialog if you want to use the WSL .ssh config.

[carlolars]

Alright, I think I know why it didn't work for me. It is because I use the ssh-agent in WSL for my keys and therefore needs an interactive shell so that .bashrc is executed to setup my ssh-agent. If I have a keyfile in .ssh/ then it works.

The problem with interactive shell is that it potentially is very slow depending on the users startup scripts. In wslgit we solved that by only using interactive shell for git commands that might require authentication (clone, fetch, pull, push, ls-remote, there may be more). Usually those commands are slow by other reasons so the extra overhead by the interactive shell is realtively small.

We also added an environment variable that was set and if the .bashrc script detected that variable then it could early exit from the startup script, or do just the bare minimal setup required for git to function.

[Stanzilla]

When I tried to pull a repo that is using SSH auth, I got this:

Warning: Identity file C:/Users/Stan/.ssh/id_rsa not accessible: No such file or directory. file is there though.

[DanPristupov]

@Stanzilla I was slightly wrong about the local (Windows) ssh keys saying

if you override the ssh config in the SSH configuration dialog, the selected key will be used instead

I didn't fix the passed SSH path because it won't work anyway:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/mnt/c/Users/tanya/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

The Linux SSH agent requires the key to not be accessed by other users (chmod 600), which is hardly achievable on Windows.

So, I guess, the only correct way to use SSH in WSL is to configure it internally.

P.S. A related discussion on stack overflow: https://superuser.com/questions/1321072/ubuntu-on-windows-10-ssh-permissions-xxxx-for-private-key-are-too-open

[carlolars]

The Linux SSH agent requires the key to not be accessed by other users (chmod 600), which is hardly achievable on Windows.

It is actually possible to have Unix permissions on files/dirs in the windows filesystem by adding the "metadata" option to wsl.conf, more info here. It works by adding metadata to the files/directories when using chmod/chown, its invisible from the windows side but makes pemissions work as expected from inside WSL.

[carlolars]

I use the ssh-agent in WSL for my keys and therefore needs an interactive shell so that .bashrc is executed to setup my ssh-agent.

I realized that I actally also require the SSH-agent when using the included Git for Windows. I opened a new issue #1170 for this as it is not only related to WSL.

[Stanzilla]

Yeah it is totally possible to set up those permissions on Windows

[Stanzilla]

...then maybe also add an option for the "Open in VSCode" to use WSL mode as well...

Already works great as a custom command:

[DanPristupov]

Yesterday we released Fork 1.63 and here is the WSL build based on 1.63: https://cdn.fork.dev/prerelease/Fork-1.63-wsl.zip

[Stanzilla]

Updated! Still works fine minus SSH!

[wtfzambo]

@DanPristupov so essentially, if I understood properly, to open a repo on WSL I need to browse \\wsl$\ in the explorer?

Is there a command that I can run from bash/zsh to open the current repo I'm working on?

Something like $ fork .

[DanPristupov]

@wtfzambo You can press Ctrl+O in Fork or drag and drop an \\wsl$\ folder from the explorer.

You can try to run %localappdata%\fork\fork.exe /absolute/path/to/repo, but I haven't tested this myself.

[Stanzilla]

@DanPristupov is there an updated WSL version of 1.64?

[b-strauss]

Yesterday we released Fork 1.63 and here is the WSL build based on 1.63: https://cdn.fork.dev/prerelease/Fork-1.63-wsl.zip

Is this still an experimental feature? Do you have an estimate when this will be merged into the normal release?

[mikemaccana]

Thanks @DanPristupov confirming the Fork-1.63-wsl.zip fixed my issue (where a pre-commit fork was using a tool that I had installed on Linux but not on Windows)

[DanPristupov]

I made WSL build based on Fork 1.64: https://cdn.fork.dev/prerelease/Fork-1.64-wsl.zip

Is this still an experimental feature?

It's still an experimental because we don't use it ourselves and can only rely on the feedback from this topic.

Do you have an estimate when this will be merged into the normal release?

We will wait at least a few more updates, I think.

[mikemaccana]

Thanks @DanPristupov this makes a huge difference (and puts Fork way ahead of other git clients). 💯

If you want to be able to test it yourself rather than rely on user feedback, just make a repo with a precommit hook that runs a Linux command (eg lsb_release) that's unlikely to have a Windows equivalent.

[Stanzilla]

@DanPristupov do you have a version of 1.65 for us, please? :)

[DanPristupov]

@Stanzilla yes

https://cdn.fork.dev/prerelease/Fork-1.65-wsl.zip

[Stanzilla]

Thank you!

[hheexx]

I just found out that WSL urls can also look like this: \wsl.localhost\Ubuntu\home\

So please add that URL format to trigger WSL mode. I lost few hours not trying to figure it out why fork tried to execute hook in windows.

[Stanzilla]

Wonder if it would also be possible to add something for gpg? Currently my WSL git config points to the WSL gpg, which fork can't pop up the password dialog for.

[Stanzilla]

@DanPristupov do you have a version of 1.66 for us, please?

[DanPristupov]

@Stanzilla https://cdn.fork.dev/prerelease/Fork-1.66-wsl.zip

The 1.66 update doesn't contain significant changes though.

[b-strauss]

@DanPristupov I just tested Fork with WSL2. It seems Fork is using the Windows Git installation (together with the Windows .gitconfig) when cloning through "File" -> "Clone..." into a \\wsl$ folder. This leads to wrong line endings inside wsl, which breaks bash files. Any ideas how to handle this? Is fork not using the git/.gitconfig version from within WSL when operating on \wsl$ folders?

[DanPristupov]

@b-strauss Fork must use the corresponding WSL instance when you clone to a \\wsl$ folder. What destination path do you see in the clone git request in the activity manager (it's located in the status control on the toolbar).

[b-strauss]

@DanPristupov i see the WSL folder

I have still installed the non WSL version alongside the "portable" WSL version. Could that be the problem ?

[DanPristupov]

@b-strauss show full git request (click on the status control).

I have still installed the non WSL version alongside the "portable" WSL version.

That must be fine, until you are opening same repository in both versions.

[b-strauss]

@DanPristupov This is the log, I removed some company info in the url/path

$ git clone --recurse-submodules git@ssh.dev.azure.com:v3/xxx/xxx/xxx "/home/b-strauss/workspace/xxx" --verbose

Cloning into '/home/b-strauss/workspace/xxx'...
remote: Azure Repos        
remote: 
remote: Found 19832 objects to send. (446 ms)

[DanPristupov]

/home/b-strauss/workspace/xxx

The unix path shows that a WSL git instance is being used (it would fail on Windows). The result must be the same as if you cloned in the WSL command line.

[b-strauss]

Ok, I'll see what happens if I clone in WSL directly.

[b-strauss]

@DanPristupov I got it working now. The .gitconfig in WSL wasn't properly configured 🙈. Thx for the help!

[Stanzilla]

@DanPristupov Here's the log file from the tweet you responded to, wasn't sure what to look for. fork.log

[hheexx]

@DanPristupov 1.67 please