git status between Windows and Linux does not agree

Question

Git status returns different results if I run it on my Linux system and my Windows10 laptop.

The original directory was started on the Linux machine (running RedHat 6.4). I got tired of editing all of our Python code using VIM, so I decided to map a network drive on my Windows10 laptop to the remote Linux box (which controls all of our test equipment) and the directory set up with Git. So now I can use Visual Studio Code to easily view/edit/update any files on the remote Linux machine. I run all my git commands from the Linux box, but it would be nice if I could run them right from VS Code, but there is obviously a difference between the two versions of Git.

'git status' --> on the Linux box returns no updated or modified files.

'git status' --> on Windows shows I have over 200 modified files and 2 directories that are deleted.

I have already looked through this thread: Git - Windows AND linux line-endings

There was a lot of great information there that I have tried. The only thing that seemed to have any effect at all though was adding the 'git config core.filemode false' setting, which I did on the Linux machine. Now, when I run 'git status' on my Windows machine I see it reduced my modified files from 200+ down to 4. So that is great. However, and I still see those 4 files as modified and the 2 folders it thinks are deleted.

Any other suggestions as to what I can check?

As a side note, I have 112 files that show up as Untracked in VS Code, but not coincidentally I believe, all 112 are files that reside in the 2 directories that Windows git status think are deleted.

Posterior

Instead of opening VSCode from the remote file share, clone from there to a local working directory on Windows. Then such issues should disappear. – Sophistry

Lex, I had done that initially. The only "problem" is that I was developing code that was in the run-break-fix stage. The code has to be on the remote Linux box to actually test because its physically connected to the hardware. So if I clone the repo on my Windows box, you are correct, it would work, but then every time I make a minor change to the code (debug print, change function, etc) I have to push it from the Windows machine and then pull it on the Linux box. I've settled on editing in VS Code on Windows but running all my Git commands from the Linux machine. – Posterior

Have you tried to set core.ignorecase to false as well in addition to core.filemode, as suggested by #43068301? That and core.filemode seem to make my Windows/Linux shared git directory to reconcile with each other. – Alfeus

Thanks Penghe, unfortunately I can't try that at this point. I switched to a MacBook and VS Code on the Mac works seamlessly with Git so I don't have this issue anymore. – Posterior

Answer 1

Git stores, in the index, some special bits of information to know easily whether a file in the work-tree is modified or not. The index itself is a file that resides within the Git repository (.git/index; there may be additional auxiliary files, and temporary index files, here, but .git/index is the index, the first and real-est, as it were).

These special bits of information in the index are (derived from) the result of operating system stat calls. The stat calls on Linux and the stat calls on Windows deliver different data (specifically st_dev, though the ino, uid, and gid can also be an issue), so a single index (and hence Git repository-and-work-tree) cannot¹ be correctly shared across a machine boundary. This holds for network drives, VM images, Dropbox folders (which have other issues), or any other sharing mechanism that allows either system to directly view the other system's data.

The end result of all of this is that it's sometimes, just barely, possible to share a Git repository this way, but it's a bad idea: you'll get odd effects, such as Git missing some modified files, or thinking files are modified when they aren't. The latter is what you're seeing, probably.

It really works a lot better, though, not to share repository directories (nor work-trees) like this. That's even true on "friendlier" systems, such as MacOS vs Linux when using VMs and, e.g., vagrant. It sort of works, sometimes, but it just is not reliable. Use separate clones and your life will be happier.

---

¹At compile time, one can choose to have Git ignore the st_dev field, to enable sharing across network drives. That sometimes makes a difference, and sometimes doesn't. I suspect this option is chosen in most Windows builds so that Windows can share with Windows, but is not enabled in Linux builds, which means the Linux side won't ignore changes made by the Windows side—which will result in odd behavior.

The timestamps are normally compatible, but if one enables nanosecond-resolution time stamps, that may also be problematic.

Semiannual

Thanks torek. Looks like I'm forced into using the Linux box for all of my git work. Which is fine, it just would have been a little more convenient if I could have done everything from my Windows laptop. Thanks for the explanation, very thorough. – Posterior

Answer 2

I use two OSs (Windows and Linux). And the git status also didn't indicate the same thing. I noticed that this happened for some repositories and not for all.

Comparing the configurations between the repositories that reported errors and the others (which git status did not indicate errors) I noticed different configurations...

For those with problem, I applied the following settings. The first one is necessary, the others I did to standardize all my repos.

git config core.fileMode false
git config core.symlinks false
git config core.ignorecase true

For more information about file.mode...

Counterpoison

Answer 3

For my case, I'm sharing the same git project between Windows and WSL, their git statuss didn't agree. When I run git diff in WSL, turns out the differences are ^Ms at the end of each line.

Then I run this in WSL:

git config --global core.autocrlf true

Everything's fixed. Refer to What are these ^M's that keep showing up in my files in emacs?

Parathion