WSL + Fork Tutorial

[Stanzilla]

I'm probably not the only one who wants to fully rely on WSL for any development work done on Windows. Yet, I still want to keep using Fork on Windows as my Git GUI of choice. Now, there are a few obstacles here but I think the community should come together and provide a tutorial for like minded people.

There are a few open issues that prevent a "perfect" flow:

• WSLGit support Support for WSL git using wslgit #305
• In part fixed by https://github.com/carlolars/wslgit#using-with-fork but would love upstream solution either in Fork or wslgit, maybe some special "WSL Mode" in Fork?
• Pass arguments to shell [Feature Request] Allow to pass arguments to preferred shell #504
• Not being able to select wsl.exe as terminal 64bit version? #385

New things that might help:

• WSL ENV https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/
• Sharing SSH keys between Windows and WSL https://devblogs.microsoft.com/commandline/sharing-ssh-keys-between-windows-and-wsl-2/

Thoughts?

[DanPristupov]

Since WSL is a virtual machine with a different file system, the majority of git operations will be very slow.

[Stanzilla]

That depends, in WSL v2, when you have your project content inside of the EXT4 volume, it's actually close to native speeds. It only becomes slow when you touch files outside of it since it has to translate everything to NTFS then.

[Haprog]

I'd love to have this working better. I'm still on WSL v1 iirc (last I checked v2 was beta or something and I didn't try it yet).

I do all my command line stuff in WSL (using zsh as my default shell and runnig it in Hyper terminal. I have Hyper setup so it automatically starts wsl.exe and it opens my default shell (zsh). I have all the needed command line tools (git, build tools etc for frontend development) installed in WSL. VS Code has good integration for WSL and it can seamlessly work with projects that are either in normal NTFS partitions or in the WSL filesystem (using their official WSL "remote" plugin).

First I tried having all my git repos in WSL too but I had problems and couldn't get Fork to work (at least some git operations were failing no matter how I tried configuring Fork).

The best workaround I have found so far is to keep my git repositories under regular windows filesystem. I can still work on them in my terminal via WSL just using a path like /mnt/c/repos. But I need to have Git installed both in WSL and also in Windows and I need to duplicate my Git configuration on both sides. Now I can use Fork with the repos normally and everything seems to work fine.

But I'd like to keep the repos in WSL if Fork would work with that kind of setup.

[Haprog]

I also tried configuring "Integration / Shell / Custom" in Fork to make the "Console" button open Hyper, but I was not able to make it open Hyper terminal in the correct directory (where the selected repository is in). Not sure if the problem is with Hyper, my Hyper config or with Fork. So now I need to open my terminal manually and navigate to the correct directory instead of a convenient button to open directly from Fork.

I used to work on macOS and there it was really nice that Fork could open iTerm in the correct dir just by clicking the Console button.

[DanPristupov]

@Haprog this is offtopic. Fork passes working directory to the selected shell application, not sure why Hyper doesn't handle it. (#504)

[Stanzilla]

This is probably a good start https://github.com/carlolars/wslgit/blob/fork-patch/README.md#usage-in-fork, currently not really working well for me though. Maybe @carlolars can provide input here?

[carlolars]

Since WSL is a virtual machine with a different file system, the majority of git operations will be very slow.

I can't say that I notice any difference in speed when using the bundled git compared to using wslgit. It must be slower yes, but it's far from very slow, not noticeable during daily use for me at least. I've used other git-GUIs that were slow for real, I was really pleased when I found Fork and paired it with wslgit.
I have my repos on the Windows filesystem which is mounted inside WSL.

[Stanzilla]

That will change come WLS2 though. You will want to move your files inside the container otherwise it's horribly slow. Talking 2min42s for a npm build here that inside of the container takes 15s. They do know about that limitation and are working on further improvements though. But it will launch this slow.

[carlolars]

Yes WSL2 will be slow I've heard, hopefully they will find a solution.

I tried to open a repository in the WSL filesystem using the UNC path, (\\wsl$\Ubuntu-18.04\tmp\gittest), but Forks directory browser can't handle such path. But if I add the repository manually to settings.json in AppData\Local\Fork then it works in Fork 😄

[Stanzilla]

Opening from \\wsl$\Ubuntu\home\stan\projects\personal worked for me but is super slow. Not using WSLGit right now, so that's probably an issue in it?

[carlolars]

Opening from \\wsl$\Ubuntu\home\stan\projects\personal worked for me but is super slow. Not using WSLGit right now, so that's probably an issue in it?

I just did some testing on accessing the WSL1 filesystem from \\wsl$ and come to think about this thread. Yea Git for Windows is super slow when accessing the WSL filesystem:

From within WSL, repo on WSL filesystem:
performance: 0.012072600 s: git command: git status -sb -uno
From Power Shell using `wslgit`, repo on WSL filesystem accessed via \\wsl$:
performance: 0.015478500 s: git command: git status -sb -uno
From Power Shell using Git for Windows, repo on WSL filesystem accessed via \\wsl$:
performance: 7.721625300 s: git command: git.exe status -sb -uno

And the numbers for accessing a repo on Windows filesystem:

From within WSL, repo on Win filesystem:
performance: 0.064751800 s: git command: git status -sb -uno
From Power Shell using `wslgit`, repo on Win filesystem:
performance: 0.065414400 s: git command: git status -sb -uno
From Power Shell using Git for Windows, repo on Win filesystem:
performance: 0.761321800 s: git command: git.exe status -sb -uno

The repo was cloned using wslgit so that is likely why Git for Windows was slower on the Windows fs, because of some attribute-mismatch or something.

[Stanzilla]

Yeah it's almost impossible to use :/