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

Question

我使用 autocrlf=true 创建了我的存储库，然后使用 autocrlf=false 进行了一些检查和提交。然后切换回 autocrlf=true (OS Win)。一切似乎都很好，直到我开始在分支之间进行一些 merge 。出现了许多 merge 冲突，其中整个文件由于更改的 eols 而被标记为已更改(我想是那些文件，使用 autocrlf=false checkout 并提交)。

有一些历史，这对我来说很有值(value)，所以我更愿意使用转换后的 eols 进行一些转换或修复提交，而不是创建新的 repo 并开始新的生活。

这是我对 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

现在我想在 autocrlf=false 下使用 GIT，所以我决定检查每个分支，使用实用程序修复源文件的 eols EOL converter并返回 CRLF。我做到了，但是过了一段时间，还有一些文件，可能是我将 autocrlf 的设置更改为 false 后没有 checkout (或者这些文件来自 merge 较旧的未固定提交？在转换过程中，我使用掩码 *.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 中有此选项。