WSL compatibility

[schummar]

Together with desktop/dugite#532, this potentially closes

• Desktop reports changes on symlink files that are not changed #10546
• Unable to commit when git hooks use bash syntax. #10060
• WSL2 repos should open in VSCode Remote #9721
• GitHub Desktop gets confused on file permissions (x-bit) in WSL #9443
• Desktop doesn't cleanly integrate with my editor (user feedback desired) #7033
• Desktop executes Script from Windows and not from WSL #14498
• Still unable to discard changes on Windows using WSL #14244
• CMD.EXE does not support UNC paths #14181
• Is it possible to integrate GitHub Desktop inside WSL2 #13953
• Git pre-commit hook fails to run because of "No such file or directory" #12586
• Desktop fails to run pre-commit hooks on node 16+ #12562
• GitHub desktop freezes on commit when there is a pre-commit hook #11997
• Allow customization of path/command to git executable #14222
• possibly more

Description

Depends on desktop/dugite#532. Together this will introduce compatibility with WSL. While you can just open a repository in WSL by entering its UNC path, this never worked right for me and many others. It suffers from

• Bad performance
• Checking out with wrong line endings (I know, can be configured, but it doesn't just work™)
• Wrongly detected changes
• Git hooks don't work

My suggestion to solve all this simple: Run git within WSL wsl.exe -e git .... The most important part is contained in the Dugite pull request. Assuming that gets merged, this PR fixes a few edge cases connected to it and improves WSL compatibility in regards to external editors and shells by

• fixing discarding files when no trash is available
• adding an option to open WSL repositories in Vs Code Remote directly
• adding an option to open WSL repositories in WSL shell, even if another shell is selected for other repos

There are certainly some things to be discussed and edge cases to be fixed. I'm happy to make adjustments based on your feedback and hope that you can see the advantage of taking this route.

Screenshots

Release notes

[niik]

Hey @schummar, thanks for wanting to contribute! I wanted to set some expectations here that we will have to have a thorough discussion internally before we can provide any feedback here and that might take a while. GitHub Desktop ships with a specific custom built version of Git because we have to be able to rely on specific features being present, localization being turned off, and specific formats of Git output that could (and do) change between versions etc. Outsourcing that to a Git version we don't have control over would be fragile at best and poses other questions around ensuring compatible versions of Git LFS being installed etc. We would likely want to run a specific dugite version within the WSL environment.

I certainly empathize with the friction you're encountering running Desktop alongside a WSL environment and it's clear that you've done a thorough job of going through the codebase to create a comprehensive solution but I want to set reasonable expectations that we won't have a lot of time to get into reviewing and considering this work in the short term.

[schummar]

@niik thanks for the reply. I didn't expect this to be quick. Of course this is a big decision and will take time, no worries.

I made the Pull Request also as a POC. The existing discussions regarding WSL were mostly "use UNC paths, it's working fine" and some tweaks and workarounds to make it somewhat workable. But that approach is fundamentally flawed and another idea is needed. I wanted to show that running git withing WSL might be such an idea. WSL is such a big deal for developers using Windows, so it deserves first class support in tools. 😉

Your point about using a specific git version makes sense. I see no issue with using an embedded git version also for WSL as well. I'll try to include this in the Dugite PR.

Whenever you had time to discuss it and if you decide that the solution has potential, I'll be happy to work with you to iron out the problems and make it production ready.

[schummar]

Your point about using a specific git version makes sense. I see no issue with using an embedded git version also for WSL as well. I'll try to include this in the Dugite PR.

I have updated the Dugite PR

[schummar]

A little script for anyone who wants to try it out:

git clone https://github.com/schummar/dugite.git
git clone https://github.com/schummar/desktop.git

cd dugite
git checkout origin/feature/wslGit
yarn
yarn build
yarn link

cd ../desktop
git checkout origin/feature/wslCompatibility
yarn
cd app
yarn link dugite
cd ..
yarn build:prod

[SynthLuvr]

I can't comment on the code because I'm unfamiliar with this repository, but I've been testing this and the user experience is vastly improved. Everything is working smoothly so far.

[SynthLuvr]

I've encountered a problem where an error is caused triggering a pre-commit hook:

resources/app/git/linux-x64/libexec/git-core/git', 'fetch', 'origin', '--tags')
return code: 128
stdout: (none)
stderr:
    git: 'remote-https' is not a git command. See 'git --help'.
    
    The most similar command is
	    remote-http

Edit: This is an edge case where GitHub Desktop errors on the first commit installing git hooks. After committing using git in the terminal, the hooks get set up properly and then GitHub Desktop works correctly for subsequent commits.

[schummar]

It seems that problem has been discussed a lot already in other issues quite a bit, so it's probably not connected to the WSL integration. See #10345 (comment).

But if you can provide a repo that demonstrates the issue, I will have a look.

[spankandex]

what do we need to have this in the master branch? it's impossible to use github for desktop with a repo in WSL

[SynthLuvr]

I've been using this branch. I do not use the main branch. Getting this merged into main branch is ideal so I can continue to get regular updates.

[schummar]

what do we need to have this in the master branch? it's impossible to use github for desktop with a repo in WSL

I am currently waiting for feedback from the team. As @niik said, it can take some time. Maybe he can provide an update some time ;-)

Btw. I merge the latest main/development branches from time to time, but be aware that using a build from this branch might be outdated and auto update can't work either.

[thesyntaxinator]

A little script for anyone who wants to try it out:

git clone https://github.com/schummar/dugite.git
git clone https://github.com/schummar/desktop.git

cd dugite
git checkout origin/feature/wslGit
yarn
yarn build
yarn link

cd ../desktop
git checkout origin/feature/wslCompatibility
yarn
cd app
yarn link dugite
cd ..
yarn build:prod

Should this be run in WSL or windows terminal?

[schummar]

In Windows Terminal.

[sarim]

I haven't looked at the details of this PR, but a good implementation for similar thing is to look at vscode. Actual vscode logic remains with vscode-server, and it's can run in any remote machine. Vscode is just the UI user interacts with. Github desktop could adopt a similar architure. Though realistically its seems kinda unfeasible considering desktop's team size / target audience.

I've been using the shiftkey/desktop fork in wsl from the start of wsl2. It is my daily driver for software development. Needed some minor issue solving from time to time, but overall it just works. Especially after introduction of WSLg, using linux version of desktop just feels more realistic.

[thesyntaxinator]

In Windows Terminal.

How do I add a repository located on WSL? I'm unable to see WSL directories in the folder selector that pops up when I click "Browse".

[schummar]

I haven't looked at the details of this PR, but a good implementation for similar thing is to look at vscode. Actual vscode logic remains with vscode-server, and it's can run in any remote machine. Vscode is just the UI user interacts with. Github desktop could adopt a similar architure. Though realistically its seems kinda unfeasible considering desktop's team size / target audience.

Yes, that would be a valid approach too. But a lot more effort, which is probably not needed for this use case.

I've been using the shiftkey/desktop fork in wsl from the start of wsl2. It is my daily driver for software development. Needed some minor issue solving from time to time, but overall it just works. Especially after introduction of WSLg, using linux version of desktop just feels more realistic.

That works generally, but I think the user experience is not optimal. WSLg windows are not as performant and seamless as native windows and if you work both on the Windows side and in WSL, you'd have to have the app installed twice.

[schummar]

In Windows Terminal.

How do I add a repository located on WSL? I'm unable to see WSL directories in the folder selector that pops up when I click "Browse".

Showing the WSL drives in Explorer has been working occasionally for me, but it's indeed very flaky. What should always work is to put the path directly into the file picker's url. E.g. \\wsl.localhost\Ubuntu where "Ubuntu" is the name of your WSL instance.

[omzy]

Is there any update on this? I'm using GitHub Desktop with a WSL mounted drive and every operation is way too slow, compared to non-WSL mounted drives.

[sarim]

Is there any update on this? I'm using GitHub Desktop with a WSL mounted drive and every operation is way too slow, compared to non-WSL mounted drives.

I think this is still experimental/under development? If you need a stable daily driver, install the linux version https://github.com/shiftkey/desktop and store code inside main wsl drive.

[schummar]

I haven't heard anything new. To proceed I would first need feedback from the team on whether they agree with the approach and what steps would need to be taken to make it production ready.

@niik can you share any update? Or what do you think are the chance that this will be discussed?

[AlejandroAkbal]

So sad that this awesome pull request does not get any attention, I would really love this to be merged and enjoy WSL development

[SynthLuvr]

What's holding this back from being merged? I've been using this for a year without issue