如何在GIT存储库中修复CRLF以避免合并冲突

Question

我使用autocrlf=true创建了我的回购，然后与autocrlf=false进行了一些结帐和提交。然后切换回autocrlf=true（OS Win）。 一切似乎都没问题，直到我开始分支之间的一些合并。出现了许多合并冲突，其中整个文件由于更改eols而被标记为已更改（我认为这些文件是已检出并随autocrlf=false提交的）。

有一些历史，这对我来说是值得的，所以我更喜欢转换或修改转换eols的提交，而不是创建新的回购并开始新的生活。

这就是我理解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一起使用，因此我决定使用实用程序EOL converter检出每个分支，修复eols源文件并使用CRLF进行提交。我做到了，但是经过一段时间后，仍有一些文件，在我将autocrlf的设置更改为false之后可能没有检出（或者这些文件是从旧的未修复的提交中合并而来的？转换我使用mask * .filetype自动处理所有LF到CRLF，因此对于我这样的情况没有其他解释）。 我还尝试touch文件，重新提交它们（正如我在stackoverflow中看到的那样）但是日期更改与GIT AFAIK无关。我也读过How to undo the damage of autocrlf，但不确定这是我的情况，也不理解巫师的伎俩。

我怎么能摆脱这个烂摊子呢？

Answer 1

使用git merge选项“ignore-space-change”或“ignore-all-space”作为“递归”策略。此选项至少在1.7.4.1中。

Answer 2

简单回答：除非您使用非Windows进行x-platform dev，否则请将其设置为false。您的源代码管理不需要为您压缩文件。在解决任何剩余的问题后，你应该飞。确保与您合作的其他人也将此设置为false。