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

我现在遇到了一个关于存储库的问题，尽管我的Git-fu通常很好，但我似乎无法解决这个问题。

当我克隆这个存储库时，然后cd到存储库中，git status显示了几个更改的文件。注意:我没有在任何编辑器或其他工具中打开存储库。

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

我已经尝试了git checkout -- .很多次，但它似乎没有做任何事情。

我使用的是Mac，存储库本身没有子模块。

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

我用事实改变了文件系统的细节!我尝试了git config --global core.trustctime false技巧，但效果不太好。

112569 次浏览
小开

我猜你用的是Windows。你链接到的GitHub页面的细节是相反的。问题是CR + LF行结束符已经提交到存储库，因为你已经将core.autocrlf设置为真正的或输入, Git想要将行结束符转换为LF，因此git status显示每个文件都被更改了。

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

git config core.autocrlf false

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

以下内容直接取自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"

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

manual.pdf      -text

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

weirdchars.txt  text
小开
最佳答案

我明白了。所有其他的开发人员都使用Ubuntu(我想)，因此都有区分大小写的文件系统。然而，我没有(因为我用的是Mac)。实际上，当我使用git ls-tree HEAD <path>查看它们时，所有文件都有小写双胞胎。

我会让他们中的一个去解决的。

小开

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

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

* text=auto

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

小开

我也有同样的问题。在Mac上也是如此。在Linux机器上查看存储库，我注意到我有两个文件:

geoip.dat和geoip.dat

我在Linux机器上删除了废弃的版本，并将存储库再次克隆到Mac上。当存在副本时，我无法提取、提交、保存或从我的存储库副本中提取。

小开

在Visual Studio中，如果你正在使用Git，你可以自动生成.gitignore和.gitattributes文件。自动生成的.getattributes文件有以下一行:

* text=auto

这一行位于文件的顶部附近。我们只需要在该行前面添加#来注释该行。在此之后，事情按预期运行。

小开

我也遇到了同样的问题。在我的例子中，我克隆了存储库，一些文件立即丢失了。

这是由于文件的路径和文件名对Windows来说太长造成的。要解决该问题，请将存储库克隆到尽可能靠近硬盘驱动器根的位置，以减少文件路径的长度。例如，将其克隆为C:\A\GitRepo而不是C:\Users Documents\yyy\Desktop\GitRepo。

小开

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

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

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

这是我目前的理解。

小开

问题也可能产生于不同的文件权限，就像我的情况:

新克隆的存储库(Windows, Cygwin):

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

裸远程存储库(Linux):

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

请执行以下命令。这也许能解决问题。

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


# Write both the index and working directory from git's database.
git reset --hard
小开
我复制了我的本地存储库到另一个文件夹和一堆修改文件显示。 我的解决方法是:我把修改过的文件藏起来，然后删除了。

.删除存储库
小开 
git config core.fileMode false

解决了我的这个问题

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

TL,博士;

core.fileMode

如果为false，则忽略索引和工作树之间的可执行位差异;对FAT等损坏的文件系统很有用。看到git-update-index(1)。

默认为true，除非git-clone(1)或git-init(1)将探测和设置core。在创建存储库时，fileMode为false(如果合适)。

小开

我发现Git将我的文件(本例中为.psd)视为文本。在.git属性中将其设置为二进制类型就解决了这个问题。

*.psd binary
小开

编辑名为.git/config的文件:

sudo gedit .git/config

或者:

sudo vim .git/config

内容

[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true


[remote "origin"]
url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
fetch = +refs/heads/*:refs/remotes/origin/*


[branch "master"]
remote = origin
merge = refs/heads/master


[branch "productapproval"]
remote = origin
merge = refs/heads/productapproval

将filemode=true更改为filemode = false。

小开

我试图做一个交互式的重基，但它声称有一些修改过的文件，所以它不让我现在做。我尝试一切回到一个干净的存储库，但没有工作。其他答案都没用。但这最终奏效了……

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

繁荣!干净的存储库。问题解决了。然后，当我执行rebase -i时，我不得不放弃最后一次提交，最后一切又干净了。奇怪的!

小开

对于新版本的macOS，这可能是由操作系统的安全特性引起的。

在我工作的存储库中，有一个二进制文件带有*。App作为文件类型。

这只是一些序列化的数据，但macOS处理所有*。app文件作为应用程序，由于该文件没有被用户下载，系统认为它不安全，并添加com.apple.quarantine文件属性，以确保文件不能执行。

但是在文件上设置这个属性也会改变文件，因此它会显示在Git更改集中，而没有任何恢复它的方法。

你可以通过运行$ xattr file.app来检查是否有同样的问题。

解决方案非常简单，只要您不需要使用该文件。只要将*.app binary添加到你的.gitattributes。

小开

我也一样。我可以看到几个同名的图片，比如“textfield .png”。和“;textfield.png"在远程Git存储库中，但不在本地存储库中。我只能看到“textfield .png”;在项目代码中没有使用。

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

多亏了山姆艾略特的答案，解决方案非常简单。首先，我让Ubuntu的一位同事删除了带有大写字母的冗余文件版本，然后提交并远程推送。

然后我运行以下程序:

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


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

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

# Local Git configuration
git config core.ignorecase true

或

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

为了防止它帮助其他人，这个问题可能还有另一个原因:不同版本的Git。我在Ubuntu 18.04 (Bionic Beaver)的机器上使用默认安装的Git版本，一切工作正常，但在Ubuntu 16.04上尝试使用Git克隆存储库时，一些文件显示为已修改。

这里的其他答案都没有解决我的问题，但是升级Git版本以匹配两个系统确实解决了这个问题。

小开

我在MacOS上遇到了相关问题。

也就是说，有些人可能没有意识到，虽然MacOS的文件系统看起来是区分大小写的，但事实并非如此。它将存储混合的案例文件名，但例如，将Foo.py和foo.py视为相同的文件。

一位同事通过从Foo.py创建foo.py作为开发脚手架的一部分创建了这样一个场景。(也就是说，不仅要强制执行PEP8模块文件命名约定，还要从原始文件中重构内容，这样我们就可以并行地完成这类工作)。当我提取这些更改时，MacOS将所有修改从foo.py覆盖到Foo.py，这导致git认为我做了本地更改，而我没有。在做一个新的克隆时，git立即声明Foo.py有显著的变化，尽管它是一个新的克隆。

解决方案是将foo.py重命名为一个完全不同的文件名，并且不与原始文件名冲突。在做出更改后，这个问题随着存储库的新克隆而消失了。

(有一个系统配置标志可以在MacOS中打开区分大小写的行为，但建议将其保留在默认设置中，因为切换该行为可能会破坏期望区分大小写的行为。)

小开

对我来说，问题是在我的MacBook上，我的Mac没有按外壳跟踪。我创建了一个APFS区分大小写的“工作空间”;分区。在那之后，我不再得到状态错误。


提交答案