Windows和Linux之间的git状态不同 [英] git status between Windows and Linux does not agree

问题描述

如果我在Linux系统和Windows10笔记本电脑上运行它，Git状态将返回不同的结果.

原始目录已在Linux机器(运行RedHat 6.4)上启动.我已经厌倦了使用VIM编辑所有Python代码的麻烦，因此我决定将Windows10便携式计算机上的网络驱动器映射到远程Linux盒(该盒控制着我们所有的测试设备)以及使用Git设置的目录.因此，现在我可以使用Visual Studio Code轻松查看/编辑/更新远程Linux机器上的任何文件.我从Linux机器上运行了我所有的git命令，但是如果我可以直接从VS Code运行它们，那就太好了，但是两个版本的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.

我已经通过以下线程进行了研究: Git-Windows和linux line-endings

我尝试了很多很棒的信息.唯一似乎没有任何作用的事情是添加了'git config core.filemode false'设置，这是我在Linux机器上完成的.现在，当我在Windows计算机上运行"git status"时，我看到它将修改后的文件从200多个减少到4个.这真是太好了.但是，我仍然看到这4个文件已被修改，并认为它删除了2个文件夹.

关于我可以检查的内容还有其他建议吗?

作为旁注，我有112个文件在VS Code中显示为未跟踪"，但并非巧合，我相信所有112个文件都位于Windows git status认为已删除的2个目录中.

解决方案

Git在索引中存储了一些特殊的信息，以方便地了解工作树中的文件是否被修改.索引本身是一个驻留在Git存储库中的文件(.git/index；这里可能有其他辅助文件和临时索引文件，但是.git/index是 the 索引，第一个也是真实的) -est).

索引中的这些特殊信息位(源自)操作系统stat调用的结果.在Linux上的stat调用和在Windows上的stat调用传递不同的数据(特别是st_dev，尽管ino，uid和gid也可能是一个问题)，因此无法在整个计算机边界上正确共享一个索引(因此也就是Git存储库和工作树) ¹ .这适用于网络驱动器，VM映像，Dropbox文件夹(存在其他问题)或任何其他允许任何一个系统直接查看另一个系统数据的共享机制.

所有这些操作的最终结果是，有时 几乎不可能以这种方式共享Git存储库，但这是一个坏主意:您会得到奇怪的效果，例如Git缺少一些已修改的文件，或者认为文件没有被修改.后者可能就是您所看到的.

这确实好得多，但不要像这样共享存储库目录(也不是工作树).甚至在使用VM和无所事事的友好"系统(例如MacOS与Linux)上也是如此.有时候，它可以正常工作，但这是不可靠的.使用单独的克隆，您的生活会更加幸福.

---

¹ 在编译时，可以选择让Git 忽略 st_dev字段，以实现跨网络驱动器共享.有时会有所作为，有时却没有.我怀疑在大多数Windows版本中都选择了此选项，以便Windows可以与Windows共享，但是在Linux版本中未启用该选项，这意味着Linux端不会忽略Windows端所做的更改-这将导致异常行为. /p>

时间戳通常是兼容的，但是如果启用了纳秒分辨率的时间戳，那么这也可能会出现问题.

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.

解决方案

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.

这篇关于Windows和Linux之间的git状态不同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！