git - 如何在GIT存储库中修复CRLF以避免 merge 冲突

我使用autocrlf=true创建了我的仓库，然后使用autocrlf=false进行了一些结帐和提交。然后切换回autocrlf=true(OS Win)。
一切似乎都还不错，直到我开始分支之间的一些 merge 。发生了许多 merge 冲突，其中整个文件由于eols的更改而被标记为已更改(我想是那些文件，这些文件已 checkout 并使用autocrlf=false提交)。

有一些历史，对我来说是值得的，因此我更喜欢使用转换后的eols进行一些转换或修复提交，而不是创建新的 repo 协议(protocol)并开始新的生活。

这就是我对autocrlf(OS Win)的理解:

如果是autocrlf=true

WorkingTree ->  commit  -> GITRepository
CRLF         CRLF to LF      LF
LF           no conv.        LF
WorkingTree <- checkout <- GITRepository
CRLF         LF to CRLF      LF

如果是autocrlf=false

WorkingTree ->  commit  -> GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF
WorkingTree <- checkout <- GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF

现在，我想将GIT与autocrlf=false一起使用，因此我决定 check out 每个分支，使用实用程序EOL converter修复源文件的eols，然后使用CRLF进行提交。我做到了，但是一段时间后，仍然有一些文件，在我将autocrlf的设置更改为false后，这些文件可能未 check out (或者这些文件从较旧的非固定提交中 merge ？自动将所有LF转换为CRLF，因此对于这种情况我没有其他解释)。
我还尝试对文件进行touch，重新提交所有文件(如我在stackoverflow中的某处所示)，但是日期更改与GIT AFAIK无关。我也阅读了How to undo the damage of autocrlf，但不确定是我的情况，也不了解向导的技巧。

请问我如何摆脱这种困惑呢？

最佳答案

将git merge选项“ignore-space-change”或“ignore-all-space”用于“递归”策略。该选项至少在1.7.4.1中。

关于git - 如何在GIT存储库中修复CRLF以避免 merge 冲突，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7187189/