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

【问题标题】：How to repair CRLF in GIT repository to avoid merge conflicts如何修复 GIT 存储库中的 CRLF 以避免合并冲突
【发布时间】：2011-11-03 11:17:52
【问题描述】：

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

有一些历史，这对我来说是值得的，所以我更喜欢使用转换后的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

现在我想将 GIT 与 autocrlf=false 一起使用，因此我决定检查每个分支，使用实用程序 EOL converter 修复源文件的 eols 并使用 CRLF 提交。我做到了，但是一段时间后，仍然有一些文件，在我将autocrlf 的设置更改为false 后可能没有检出（或者这些文件是从较旧的不固定提交中合并的？在转换过程中我使用了掩码*.filetype 自动处理所有 LF 到 CRLF，所以对我来说这种情况没有其他解释）。我还尝试touch 文件，重新提交所有文件（正如我在stackoverflow 中的某处看到的那样），但日期更改与GIT AFAIK 无关。我也看过How to undo the damage of autocrlf，但不确定是不是我的情况，也不懂巫师的把戏。

请问我怎样才能摆脱这种混乱？

【问题讨论】：

你试过autocrlf=input吗？如果您的回购没有公开，您可以使用它和filter-branch --index-filter 来清理历史记录中的行尾
@knittl：如果我理解的话，这将用 LF 重写历史上的所有提交。我对吗？然后我可能必须在结帐后转autocrlf=true 才能获得CRLF（OS Win）。是否可以选择将 repo 直接转换为 CRLF 并在此之后离开 autocrlf=false？
一旦将存储库转换为 CRLF，您应该能够拥有autocrlf=false，因此不会转换行结尾并保持文件中的原样
@knittl：所以设置autocrlf=input 会导致在提交期间转换，在结帐期间没有转换。 Windows机器上到底发生了什么？存储库将全部为 CRLF，还是全部为 LF？我在手册中找不到这个。谢谢。
来自git config manpage：»此变量可以设置为input，在这种情况下不执行输出转换。«

标签： git core.autocrlf

【解决方案1】：

简单的回答：除非您正在使用非 Windows 进行 x 平台开发，否则请将其设置为 false。您的源代码控制无需为您的文件混蛋。解决任何剩余问题后，您应该飞行。确保与您一起工作的其他人也将其设置为 false。

【讨论】：

我建议在 Windows 上将此选项始终设置为 true - 如果您真的不这样做，您会在其他平台上遇到很多麻烦。

【解决方案2】：

对“递归”策略使用 git 合并选项“ignore-space-change”或“ignore-all-space”。这个选项至少在 1.7.4.1 中。

【讨论】：