GitHub Desktop gets confused on file permissions (x-bit) in WSL

[bert-laverman]

Describe the bug

GitHub Desktop mistakenly marks files which have the x-bit set (mode 0755 on MacOS and Linux) as changed when the checked out repo is on a WSL "share".

Version & OS

GitHub Desktop 2.4.0, Windows 10 Pro, WSL 2 (Windows preview "slow" channel)

Steps to reproduce the behavior

1. Open WSL 2
2. go to a directory on a non-Windows location, e.g. your WSL home directory, not "/mnt/c/Users/xyz".
3. Do a "git clone" of any repository containing executable scripts, such as shell scripts or Python programs.
4. Ensure the files have the 0755 mode, aka "rwxr-xr-x" and that this is the mode of the file on GitHub in the rep. Use "git ls-files -s" to verify.
5. Open GitHub Desktop, and add the repo as a local repo. It will be under "\\wsl$\home\<user>".
6. The error: GitHub Desktop will show all scripts as "Changed files", even though nothing was actually changed. Running "git status" on the WSL commandline will show that actually nothing has changed.

Expected behavior

GitHub Desktop should show that nothing has actually changed.

Actual behavior

GitHub Desktop shows files as changed and wants them to be checked in.

[outofambit]

@bert-laverman thanks for filing this issue! I'm sorry you're experiencing this. Since this involves WSL (effectively running Linux on a Windows system) and we don't support Linux I'm not sure where this falls on our support commitment. @desktop/product could you provide some guidance here?

@bert-laverman have you been found any workarounds that are helpful? I'm imagining moving the repo to a non-WSL folder might be one? Could you also help clarify what you mean by a "WSL share"?

[bert-laverman]

@outofambit This was a learning trajectory for me too. I found out that the "\\wsl$\<distro-name>" prefix will give you a pseudo-SMB share of the WSL2 filesystem, with all the consequences of such shares: File protection bits are not propagated properly, so if you run Windows-git on it, you should prevent trouble and disable the filemode bits.

That said, if you could actually use the "wsl" prefix and run Linux Git on the actual underlying filesystem. So, if GitHub Desktop on Windows wants to properly support WSL(2), you should replace the running of Windows Git with Git-for-Linux using the WSL prefix. So the "Add repository" dialog must allow the user to select "WSL filesystem", with a drop-down of the Distros. Then you know you can access the files directly using "\\wsl$\<distro-name>" and adjust all runs of CLI Git.

I just tested, and the following worked:

C:\Users\user> wsl -d Ubuntu-18.04 -u user cd /home/user/dev ; ls -l
total 8
drwxr-xr-x 27 user user 4096 Apr 15 15:08 JavaDev
drwxr-xr-x  3 user user 4096 Apr 14 13:32 Support

C:\Users\user>

Or, more appropriately:

C:\Users\user>wsl -d Ubuntu-18.04 -u user cd /home/user/dev/JavaDev/running-axon-server ; git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        renamed:    2-docker/3-docker-compose-se/docker-compose-win.yml -> 2-docker/3-docker-compose-se/docker-compose-unnamed.yml

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        2-docker/3-docker-compose-se/README.md


C:\Users\user>

[bert-laverman]

Suggestion: make the "git" command a configurable option, so we can use the above instead of "standard Windows git"? My knowledge of JavaScript/TypeScript for desktop apps is definitely not enough to suggest a PR.

[trulysinclair]

Hey, so what I've noticed is that WSL2 has a notoriously slower I/O with Windows filesystem which they openly admit. So GitHub Desktop should support SSH into WSL instead of trying to access the filesystem. We're experiencing false changes, which the diffs show nothing. So the permissions are causing false changes, and when trying to commit Desktop just errors out.

I stated SSH as VS Code remotes into WSL, but using the wsl prefix should work just as well

[Adrianilloo]

This is what I did to solve this.

• On Windows, using Git Bash for instance: git config --global core.fileMode false
• On WSL terminal: git config --global core.fileMode true.
  Also, in case you didn't have this setting when cloning repositories on WSL, you need to disable explicitly it per repository:
  git config --local --unset core.fileMode. According to the docs:

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].

The default is true (when core.filemode is not specified in the config file).`

After this, I no longer see changes caused by filemode changes done in WSL at GitHub Desktop. Note the "false" changes are also reported when running a simple git diff on Windows Git, so I don't think this is really a Desktop bug.

[Anthropic]

@Adrianilloo I couldn't get the suggestion above to work with WSL2 no matter which combination I tried
Was there anything you did at all that isn't in the comment above?

[Adrianilloo]

@Anthropic Not that I can think of. To reproduce the issue (or test my solution), you need to ensure that you have a file committed with executable bit (double check with with an ls on WSL and ensure it's committed via git status), then see what happens when you run git status on Git Bash. The change detection (either happening or not) should be matching in GitHub Desktop.

Also, I did some tests to check how my suggested setup can affect loosing the executable bit upon a git rebase from Windows (Git Bash): it turns out that independently of the applied core.fileMode value, squashing (unifying) commits where a file with executable bit/s is involved always removes these bits not just in the working directory, also in the internal Git index, so if you git push -f <branch> from that terminal, the bit will be definitely gone in the remote. The only problem having core.fileMode disabled causes, is it increases the likelyhood of performing a rebase (for these people that are used to it) inadvertedly of the executable bit/s being completely lost internally, because when the setting is true, you can't perform a git rebase since git status shows changes on the working directory due to the "normal" executable bit loss issue, so you would require some effort by executing git restore <file> to clean the working directory (git reset --hard doesn't work in this case), rather than instinctively switching to WSL and rebasing from there, where the executable bit won't be affected.

However, I've run the same git rebase tests with both core.fileMode values when repository is normally cloned on Windows from the remote (so not coming from WSL), and, even when ls never shows the executable bits, they never get removed internally from Git when squashing commits involving executable files. Casually, I've also found cloning on Windows (so including GitHub Desktop) always sets core.fileMode to false on the repository. So indeed it is done for a good reason.

I hope this extra information comes useful for anyone.

[Anthropic]

@Adrianilloo I got it to work, it just needed a full system re-start before trying commands a second time, then it worked.
Thank you for the first post and the follow up, champion effort, thanks 👍

ps. I did restart in prior attempts, but then after shutting down, it just worked the next time I started my laptop and tried again.

[steve-kidreads-app]

While manually disabling filemode on Windows git can get around this issue, the better fix for GitHub Desktop is probably to detect that the target dir is within the WSL filesystem and use WSL git (along the lines of what @bert-laverman suggested above, but automatic). Basically, it should operate like "WSL Remote" mode in VS Code:
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

The logic to detect that the target dir is in the WSL filesystem is the same as what would be required for the related feature request #9721.

[TonyTheFerg]

So, is there any documentation / workable solution on using GitHub Desktop to push and pull files that are in WSL2? I am on Windows 10 Pro build 19043.1110, With Ubuntu 20.04. It would be really nice to be able to add a repository from WSL2 to GitHub Desktop.

[b-hayes]

Yeah, this sucks.
You'd think WSL support would be a thing by now its more than a year since it was getting adopted by a LOT of people. same.

Just tried GitHub desktop again coz I miss it and haven't been able to use it since I moved to WSlv2. And it's actually a lot worse now.

FYI what people say about WSL2 having slow IO with windows file system while true is irrelevant. If we could just tell GitHub to use the git binary inside WSL not only will all the problems go away but the IO performance will probably be much faster than windows git on NTFS as IO performance in WSL2 is actually super fast. It is just obviously slow if your accessing pseudo network mounts to a windows files system from within a pseudo-Linux VM.

Until this issue is resolved guess I have to forget Github desktop again to go back to using git cola. 😢
🚪🚶‍♂️...

PS - To others looking for workaround:
Either edit your global git config on windows to ignore file modes and use Unix line endings and made sure it exactly matches your Linux git behaviour.
OR
Install and run Linux GUI applications from inside the WSL terminal but you must install an X server and configure Linux display variable to send GUI to windows and manually adjust them for your windows UI scaling etc. There is a discarded GitHub desktop for Linux that someone is kindly maintaining and there is also git cola that's is pretty good too.

[ayoubayari]

This is what I did to solve this.

• On Windows, using Git Bash for instance: git config --global core.fileMode false
• On WSL terminal: git config --global core.fileMode true.
  Also, in case you didn't have this setting when cloning repositories on WSL, you need to disable explicitly it per repository:
  git config --local --unset core.fileMode. According to the docs:

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].

The default is true (when core.filemode is not specified in the config file).`

After this, I no longer see changes caused by filemode changes done in WSL at GitHub Desktop. Note the "false" changes are also reported when running a simple git diff on Windows Git, so I don't think this is really a Desktop bug.

BRO U FANTASTIC

[ManalLiaquat]

This is what I did to solve this.

• On Windows, using Git Bash for instance: git config --global core.fileMode false
• On WSL terminal: git config --global core.fileMode true.
  Also, in case you didn't have this setting when cloning repositories on WSL, you need to disable explicitly it per repository:
  git config --local --unset core.fileMode. According to the docs:

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].

The default is true (when core.filemode is not specified in the config file).`

After this, I no longer see changes caused by filemode changes done in WSL at GitHub Desktop. Note the "false" changes are also reported when running a simple git diff on Windows Git, so I don't think this is really a Desktop bug.

It works like a charm ✨

[arslangzr]

This is what I did to solve this.

* On Windows, using Git Bash for instance: `git config --global core.fileMode false`

* On WSL terminal: `git config --global core.fileMode true`.
  Also, in case you didn't have this setting when cloning repositories on WSL, you need to disable explicitly it per repository:
  `git config --local --unset core.fileMode`. According to the docs:

A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].

The default is true (when core.filemode is not specified in the config file).`

After this, I no longer see changes caused by filemode changes done in WSL at GitHub Desktop. Note the "false" changes are also reported when running a simple git diff on Windows Git, so I don't think this is really a Desktop bug.

It Worked... Thanks man

[eth0net]

Any chance this can be included somewhere in GitHub Desktop docs or in the app itself? The fix mentioned here works perfectly but had to dig around to find it

[bert-laverman]

Sorry, I haven't visited this issue for a while.

I see above that you can solve the issue by playing ostrich and simply disabling file mode bits in Windows-git. Is that really what we want as a solution? I work in an environment where repositories will be used on Linux, Windows, and macOS, and disabling file mode bits would invite the dreaded "works on my machine" response to issues with them.

Is it so hard to expose the actual call to the git command-line utility and make it configurable? Or does GitHub Desktop use its own implementation in JavaScript? Again: the command-line utility sometimes does it correctly, and being able to use "wsl git" instead would solve it completely.

[eth0net]

I see above that you can solve the issue by playing ostrich and simply disabling file mode bits in Windows-git. Is that really what we want as a solution? I work in an environment where repositories will be used on Linux, Windows, and macOS, and disabling file mode bits would invite the dreaded "works on my machine" response to issues with them.

That's actually a really good point... While this fix works for me in this situation, it would not work within many projects, as you say

[miqrogroove]

For folks who are totally new to this, I found three ways to update the Windows config:

%LOCALAPPDATA%\GitHubDesktop\app-3.3.6\resources\app\git\cmd\git.exe config --global core.fileMode false

OR

Use a text editor to open %USERPROFILE%\.gitconfig

OR

In GitHub Desktop go to File > Options > Git > edit your global Git config file.

For those last two methods, this would be appended manually to the config:

[core]
	fileMode = false
	autocrlf = false

As explained earlier in this thread, it was also necessary to set fileMode false in the repo local config, and fileMode true in the linux client.