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

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.

[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.

[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>