Question

在合并我的同事的捆绑后，我发现了CRLF问题。有时将带有LF的行混合到源中，可能是合并到的源。因此，我们决定添加.gitattributes文件，其中包含以下内容（已删除评论）：

*.cpp text
*.h text
*.inc text
*.cfg text
*.dic text

*.sln text eol=crlf
*.vcxproj text eol=crlf
*.filters text eol=crlf
*.user text eol=crlf
*.rc text eol=crlf
*.rc2 text eol=crlf

现在我观察到这种奇怪的行为。我可以看到很多不应该存在的modified: ...个文件（即未分级的）。我试过git reset --hard，但文件仍然具有相同的状态。我试图再次克隆存储库 - 结果相同。

我已从git version 1.7.11.msysgit.0安装了Git-1.7.11-preview20120620.exe作为Windows的当前版本下载。

我还应该尝试什么？

谢谢，彼得

Answer 1

原因

* text=auto中的.gitattributes设置会导致此问题。你可以删除它并过上幸福的生活，但是你的repo可能包含非repo-default行编码的文件，甚至包含几个不同行结束编码的文件（即LF和CRLF，甚至CR！）。

为什么会发生这种情况（详情）

当git按原样检出文件时，将在添加/提交时修改行结尾。该文件实际上尚未修改，但是git已经将其视为已修改，因为它将是，这是由于repo的设置。

不知何故，它对git有点奇怪。例如，git reset --hard有时会有效，有时可能无效，可能取决于您的设置。或者，如果您进入.gitattributes并将扩展名标记为二进制文件，那么已修改的文件会神奇地消失：

*.ext binary

即使在再次执行git reset --hard之后，即使删除了二进制标记，效果也会保留，因此可能是git bug或git缓存问题。对文件执行git -rm，然后执行git reset --hard恢复已修改的标记。

如何解决

我们在此假设您要保留* text=auto设置，以便git警告您现在和将来在各种文本文件中存在不一致的行结尾。如果是这样，请选择您的方法：

选项0 ：暂时欺骗git将文件标记为已修改

修改.gitattributes，注释掉* text=auto，保存
git status（此步骤需要在.gitattributes中进行git记录更改）
git reset --hard（这将恢复* text=auto，并且如果你做了任何更改，也可以修改工作目录中的任何更改。

这通常有效（除非在大多数情况下都是例外）。它也推迟了这个问题，这个问题很可能会在某些时候出现，因为行结尾仍未正常化。

当你必须倒回一个尚未规范化的先前提交时，这个选项很棒，比如在rebase或其他git工作期间，你知道现有的后续提交会规范化行结尾，但git会抱怨修改后的文件现在阻止你继续。因此，当你需要git来关闭并忽略那些真正没有为你的特定环境修改过的修改过的文件时，基本上就会使用这个方法。

选项1 ：简单的“最终用户”修复

如果您只有几个文件，请确保您的.gitattributes和core.autocrlf符合您的喜好，然后只需制作一个git add/commit即可再次看到此问题。这些文件将转换为您想要的行结尾并存储在您的仓库中，如配置中所述。此提交将作为“整个文件已更改”存储在您的仓库中，因为每行都会更改其行结尾。对于较大或开源的回购中的一些文件，这很好。一定要合并或挑选提交到所有分支，因为问题将存在于具有这些文件的所有分支中，直到您修复它为止。顺便说一下，你可以在这里使用Option 0.即如果你切换到一个不固定的分支，并且它抱怨，运行Option 0，然后进行修复（merge或cherry-pick）。

重要提示：如果您要使用选项1的此路线，请务必正确转换已修改的文件。 git可能没有像你期望的那样为你做，所以在你提交之前自己做，即使用它：Converting newline formatting from Mac to Windows git可能会混淆的原因是我看到的文件有三个CR，LF，和CRLF行结束格式化。在提交之前自己将这些格式化为您的首选格式。

选项2 ：高级机制“git history rewriting”修复：

如果你有一个更私人的回购并且不怕重写历史，请看看： git sees entire file as one line due to mac line endings 这将重写整个仓库，并在所有树木，树枝上永远摆脱任何线路终止问题！请务必包含您可能要标准化的所有潜在麻烦的文本文件扩展名，否则它们可能会在以后显示。

在我的情况下，我做了选项2，因为我在许多分支机构处理大量文件结束问题。但后来我有一些意想不到的扩展显示我没有正常化，只做了选项1，因为我只错过了5-6个文件。

git reset问题 - 添加.gitattribute后的硬盘 - 不应该存在的本地更改

1 个答案:

原因

为什么会发生这种情况（详情）

如何解决