在 Git 克隆后直接显示为已修改的文件

Files showing as modified directly after a Git clone

提问by Sam Elliott

I'm having an issue with a repository at the moment, and though my Git-fu is usually good, I can't seem to solve this issue.

我目前的存储库有问题，虽然我的 Git-fu 通常很好，但我似乎无法解决这个问题。

When I clone this repository, then cdinto the repository, git statusshows several files as changed. Note: I haven't opened the repository in any editor or anything.

当我克隆这个存储库，然后cd进入存储库时，会git status显示几个已更改的文件。注意：我没有在任何编辑器或任何东西中打开存储库。

I tried following this guide: http://help.github.com/dealing-with-lineendings/, but this didn't help at all with my issue.

我尝试遵循本指南：http: //help.github.com/dealing-with-lineendings/，但这对我的问题根本没有帮助。

I have tried git checkout -- .many times, but it seems not to do anything.

我尝试了git checkout -- .很多次，但似乎没有任何作用。

I'm on a Mac, and there are no submodules in the repository itself.

我在 Mac 上，并且存储库本身中没有子模块。

The filesystem is "Journaled HFS+" filesystem on the Mac and is not case-sensitive. The files are one-line and about 79 KB each (yes, you heard right), so looking at git diffisn't particularly helpful. I have heard about doing git config --global core.trustctime falsewhich might help, which I will try when I get back to the computer with the repository on it.

文件系统是 Mac 上的“Journaled HFS+”文件系统，不区分大小写。这些文件是一行的，每个文件大约 79 KB（是的，你没听错），所以查看并git diff没有特别的帮助。我听说过这样做git config --global core.trustctime false可能会有所帮助，当我回到带有存储库的计算机时，我会尝试这样做。

I changed details of filesystem with facts! And I tried the git config --global core.trustctime falsetrick which didn't work very well.

我用事实更改了文件系统的详细信息！我尝试了git config --global core.trustctime false一个效果不佳的技巧。

采纳答案by Sam Elliott

I got it. All the other developers are on Ubuntu (I think) and thus have case-sensitive file systems. I, however, do not (as I'm on a Mac). Indeed, all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.

我知道了。所有其他开发人员都使用 Ubuntu（我认为），因此具有区分大小写的文件系统。但是，我没有（因为我在 Mac 上）。事实上，当我使用git ls-tree HEAD <path>.

I'll get one of them to sort it out.

我会找他们中的一个来解决。

回答by adnans

I had the same problem on the Mac after cloning a repository. It would assume all files had been changed.

克隆存储库后，我在 Mac 上遇到了同样的问题。它将假设所有文件都已更改。

After running git config --global core.autocrlf input, it was still marking all files as changed. After looking for a fix I came across .gitattributesfile in the home directory which had the following.

运行后git config --global core.autocrlf input，它仍然将所有文件标记为已更改。在寻找修复程序后，我.gitattributes在主目录中遇到了以下文件。

* text=auto

I commented it out and any other cloned repositories from now on were working fine.

我把它注释掉了，从现在起任何其他克隆的存储库都可以正常工作。

回答by Piotr Korlaga

git config core.fileMode false

solved this problem in my case

在我的情况下解决了这个问题

https://git-scm.com/docs/git-config

https://git-scm.com/docs/git-config

TL;DR;

TL; 博士;

core.fileMode

核心文件模式

If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).

如果为 false，则忽略索引和工作树之间的可执行位差异；在损坏的文件系统（如 FAT）上很有用。请参阅 git-update-index(1)。

The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.

默认为 true，除了 git-clone(1) 或 git-init(1) 将在创建存储库时探测并设置 core.fileMode 为 false。

回答by Arrowmaster

I assume you are using Windows. That GitHub page you linked to has the details backwards. The problem is that CR + LF line endings have been committed to the repository already and because you have core.autocrlfset to either trueor input, Git wants to convert the line-endings to LF, so git statusshows that every file is changed.

我假设您使用的是 Windows。您链接到的那个 GitHub 页面有向后的详细信息。问题是 CR + LF 行结尾已经提交到存储库，并且因为您将core.autocrlf设置为true或input，Git 想要将行结尾转换为 LF，因此git status显示每个文件都已更改。

If this is a repository that you only want to access, but have no involvement with, you can run the following command to merely hide the issue without actually solving it.

如果这是一个您只想访问但不参与的存储库，您可以运行以下命令来隐藏问题而不实际解决它。

git config core.autocrlf false

---

---

If this is a repository that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repository to use LF instead of CR + LF and then take steps to prevent it from happening again in the future.

如果这是一个您将积极参与并可以提交更改的存储库。您可能希望通过提交将存储库中的所有行结尾更改为使用 LF 而不是 CR + LF 的提交来解决问题，然后采取措施防止将来再次发生。

The following is taken directly from the gitattributes man pageand should be preformed from a clean working directory.

以下内容直接取自gitattributes 手册页，应从干净的工作目录中执行。

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.

如果任何不应规范化的文件出现在 中git status，请在运行前取消设置它们的文本属性git add -u。

manual.pdf      -text

Conversely, text files that Git does not detect can have normalization enabled manually.

相反，Git 未检测到的文本文件可以手动启用规范化。

weirdchars.txt  text

回答by kds

Please run the following commands. That might solve the issue.

请运行以下命令。那可能会解决问题。

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

回答by J Adam Rogers

In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:

在 Visual Studio 中，如果您使用 Git，则可以自动生成 .gitignore 和 .gitattributes 文件。自动生成的 .getattributes 文件包含以下行：

* text=auto

This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.

这一行靠近文件的顶部。我们只需要通过在它前面添加一个 # 来注释掉该行。这样做之后，事情按预期进行。

回答by Gima

The problem might also arise from differing file permissions, as was my case:

问题也可能来自不同的文件权限，就像我的情况：

Fresh cloned repository (Windows, Cygwin):

新克隆的存储库（Windows、Cygwin）：

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Bare remote repository (Linux):

裸远程存储库（Linux）：

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

回答by Dennis

I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.

我想添加一个更针对“为什么”发生这种情况的答案，因为已经有一个关于如何解决它的好答案。

So, .gitattributeshas a * text=autosetting, which causes this issue.

所以，.gitattributes有一个* text=auto设置，这会导致这个问题。

In my case, files on GitHub's master branch had \r\nendings. I have dialed up the settings on the repository to check-in with \nendings. I don't know what Git checks out though. It is supposed to check out with native endings onto my Linux box (\n), but I guess it checked out the file with \r\nendings. Git complains because it sees the checked out \r\nendings that were in the repository and warns me that it will check in \nsettings. Hence files are "to be modified".

就我而言，GitHub 主分支上的文件有\r\n结尾。我已经拨打了存储库上的设置以签入\n结尾。我不知道 Git 检查了什么。它应该以本机结尾在我的 Linux 盒子 ( \n) 上签出，但我猜它签出了带有\r\n结尾的文件。Git 抱怨是因为它看到了\r\n存储库中已检出的结尾，并警告我它将检入\n设置。因此文件是“要修改的”。

That's my understanding for now.

这是我目前的理解。

回答by user2148301

I had the same problem. Also with a Mac. Looking at the repository on a Linux machine I noticed that I had two files:

我有同样的问题。还有Mac。查看 Linux 机器上的存储库，我注意到我有两个文件：

geoip.dat and GeoIP.dat

geoip.dat 和 GeoIP.dat

I removed the deprecated one on the Linux machine and cloned the repository again to the Mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.

我在 Linux 机器上删除了已弃用的一个，并再次将存储库克隆到 Mac。当存在重复项时，我无法从我的存储库副本中提取、提交、存储或提取。

回答by Adrian

The same issue for me. I could see several images with the same name, like "textField.png" and "textfield.png" in the remote Git repository, but not on my local repository. I was only able to see "textField.png" which was not used in the project's code.

对我来说同样的问题。我可以在远程 Git 存储库中看到多个具有相同名称的图像，例如“textField.png”和“textfield.png”，但在我的本地存储库中看不到。我只能看到项目代码中未使用的“textField.png”。

It turns out most of my colleagues are on Ubuntu using ext4filesystem whereas I'm on a Mac using APFS.

事实证明，我的大多数同事都在使用ext4文件系统的Ubuntu 上，而我在使用 APFS 的 Mac 上。

Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.

感谢Sam Elliott的回答，解决方案非常简单。首先我让Ubuntu上的一个同事删除了大写的冗余文件版本，然后提交并远程推送。

Then I ran the following:

然后我运行了以下命令：

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Finally, we decided that every developer should change his Git configuration to prevent this to ever happen again:

最后，我们决定每个开发人员都应该更改他的 Git 配置以防止这种情况再次发生：

# Local Git configuration
git config core.ignorecase = true

or

或者

# Global Git configuration
git config --global core.ignorecase = true