为什么要在 Git 中使用 core.autocrlf=true ？

我有一个可以从 Windows 和 OS X 访问的 Git 存储库，并且我知道它已经包含一些带有 CRLF 行结尾的文件。据我所知，有两种方法可以解决这个问题：

1. Set core.autocrlf to false到处，

2. 按照说明操作here（在 GitHub 的帮助页面上呼应）将存储库转换为仅包含 LF 行结尾，然后设置core.autocrlf to true在 Windows 和input在 OS X 上。这样做的问题是，如果我在存储库中有任何二进制文件：

   1. 没有在 gitattributes 中正确标记为二进制，并且
   2. 碰巧同时包含 CRLF 和 LF，

   他们将会被腐蚀。我的存储库可能包含此类文件。

那么为什么我不应该关闭 Git 的行结束转换呢？网络上有很多关于以下内容的含糊警告：core.autocrlf关闭会导致问题，但很少specific那些;到目前为止我发现的唯一问题是 kdiff3 无法处理 CRLF 结尾（对我来说不是问题），并且某些文本编辑器存在行结束问题（对我来说也不是问题）。

该存储库是我公司内部的，因此我无需担心与具有不同 autocrlf 设置或行结束要求的人员共享它。

只保留行结尾是否还有我不知道的其他问题？

唯一设置的具体原因autocrlf to true are:

• avoid git status将所有文件显示为modified因为在将基于 Unix 的 EOL Git 存储库克隆到 Windows 存储库时会完成自动 EOL 转换（请参阅issue 83例如）
• and your coding tools somehow depends on a native EOL style being present in your file:
  • 例如，硬编码代码生成器来检测本机 EOL
  • 其他外部批次（存储库外部），带有正则表达式或代码集来检测本机 EOL
  • 我相信一些 Eclipse 插件可以生成带有 CRLF 的文件，无论平台如何，这可能是一个问题。
  • 您使用 Notepad.exe 进行编码（除非您使用的是 Windows 10 2018.09+，其中记事本尊重检测到的 EOL 字符).

除非你能看到具体的治疗方法must处理原生 EOL，你的情况会更好leaving autocrlf to false (git config --global core.autocrlf false).

请注意，此配置将是local一个（因为配置不会从一个存储库推送到另一个存储库）

如果您希望克隆该存储库的所有用户使用相同的配置，请查看“什么是最好的CRLF用git处理策略？“， 使用text属性中的.gitattributes file.

Example:

*.vcproj    text eol=crlf
*.sh        text eol=lf

注意：从 git 2.8（2016 年 3 月）开始，合并标记将不再在 CRLF 文件中引入混合行结尾 (LF)。
See "让 Git 在其“"