33

When I run git status on a git repository through WSL (Windows Subsystem for Linux) that's on the Window's directory (/mnt/c/Users/....), I get that every file in the directory has been modified. Each modification is just delete and re-write of the original file. See below: enter image description here

Below is a git diff on one of the files git diff on specific file

Now if I run a git status on the exact same repository on the Windows side (through powershell), I get nothing:

enter image description here

Any particular reason behind this? I know the ^M have to do with the different line endings that Linux and Microsoft are using, but that git would disagree on whether changes have been made or not seems odd to me.

Note: I've been working on the repository on WSL side through a separate clone of the repository (hence why the Windows side is 15 commits behind). No editing has been done to the Windows repository though. Not sure if this changes anything, but I'd figure I'd mention it.

James Wright
  • 1,293
  • 2
  • 16
  • 32

2 Answers2

40

The two git installations (native windows and WSL) are using a different setting for the core.autocrlf configuration, because these two installations are not using the same global config file.

Put simply, the native windows client is converting LF to CRLF upon checkout, and hence the presence of CRLF is not "seen" as a change by git status. On the contrary, the WSL client expects UNIX-style LF line endings, so the git status sees every file as having been modified to change LF to CRLF.

Instead of relying on the global setting the core.autocrlf you should set it locally in the repository for any shared repositories. If the same repository is being accessed from both Linux/WSL and native Windows, you probably want this set to false so git does not change any line endings at all. Just beware that if you do set this as false, you'll have to make sure your editors can handle the line endings as they are (in general, most programmers editors I've used do support using UNIX LF, even on Windows).

The core.autocrlf is documented here for more info:

https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_core_autocrlf

user1338062
  • 11,939
  • 3
  • 73
  • 67
Joe Hickey
  • 810
  • 7
  • 8
  • Good job man - thank you very much :) I had no idea that this was an issue at all.. It seems kinda stupid :) – IncrediblePony Nov 25 '19 at 09:14
  • 4
    I have set `core.autocrlf` in WSL environment to `true` to mimic the behavior of Windows (as the IDEs run in Windows as well). That might be an option as well. On a fresh system starting with it OFF and simple using LF might be better (and every IDE supports that) but I did not want to disturb the existing repo... – ZoolWay Apr 15 '20 at 12:41
  • I use `autocrlf:false`, see my comment to [this post](https://stackoverflow.com/a/10419350/1705829) – Timo Jun 04 '21 at 06:00
  • I wonder if it would be possible to set this automatically based on the file path? I would prefer if all my repos under /mnt/c/ automatically used windows line endings even in WSL, and all repos under the WSL filesystem used unix line endings. – Ryan McCampbell Aug 12 '23 at 20:29
4

This could have something to do with WSL reporting the permissions of all files on the Windows filesystem as being 777. Git then regards all files as changed because their permissions are different.

Try changing the Git configuration so that permission changes are ignored:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

See: https://github.com/microsoft/WSL/issues/184

Stanislav Kuhlevskiy
  • 59
  • 1
  • 4