Question

我将用解决方案回答我的问题，解决了我的问题。

关于downvoters的注意事项：我理解根本原因会在各种其他线程中讨论（这就是我解决问题的方法）。这篇文章更多的是关于双启动系统如何引导您解决此问题。所以不，这个问题/答案不是重复的，而是一般问题类的特定实例，在此问题上向SO的存储库添加了更多案例。

在家：我在Linux中编码。 LF用作行结尾
在办公室：我在Windows中编码。 CRLF用作行结尾。
默认情况下，git的autocrlf功能（https://stackoverflow.com/a/20653073/2715083）让事情变得愉快。

但是，如果你使用Linux和Windows运行双启动系统，你可以通过以下方式搞砸自己：

git pull您在Windows环境中的Linux环境中处理的一些文件，位于可以从双启动的Linux环境中访问的位置。这会修改文件以包含CRLF结尾。
然后当你在linux中打开文件时，默认值只有LF，git diff会说整个文件被修改，因为每个LF在每一行都变为CRLF。（我被Atom警告，内置了这个差异计数）

Answer 1

你正在谈论text = auto part吗？我不确定是否需要将其包含在新的.gitattributes文件中，因为当我这样做时， ATOM仍然会将文件显示为已修改。

是的，确实如此要强制Git应用.gitattributes指令，请参阅“Dealing with line endings”。

我首先要确保将core.autocrlf设置为false。

git config --global core.autocrlf false

然后：

git add . -u
git commit -m "Saving files before refreshing line endings"

rm .git/index

git reset

git status

git add -u
git add .gitattributes

git commit -m "Normalize all the line endings"

您还可以使用，强制索引重新规范化：

git rm --cached -r .
git reset --hard

请参阅“Force LF eol in git repo and working copy”

* text=auto eol=lf

Answer 2

FIX

删除/移动到问题文件/文件夹的其他位置
执行git checkout <hash> <your/files/location>

其中<hash>用于上次良好提交，your/files/location是您要从CRLF问题中治愈的文件的位置。这基本上将从本地.git存储库中恢复旧版本。

为我工作。

如果你知道我错过了什么，或者解释不正确，请告诉我

git - Windows + linux双启动中的CRLF问题

2 个答案: