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

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

1. 设置core.autocrlf到false无处不在，

2. 按照此处的说明（在GitHub帮助页面上显示）将存储库转换为仅包含LF行尾，然后在Windows和OS X上将其设置core.autocrlf为。这样做的问题是，如果存储库中有任何二进制文件那：trueinput

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

   他们将被破坏。我的存储库可能包含此类文件。

那么，为什么不关闭Git的行尾转换呢？网路上有很多模糊的警告，提示您core.autocrlf关闭电源会导致问题，但很少有具体的警告。到目前为止，我唯一发现的是kdiff3无法处理CRLF结尾（对我来说不是问题），并且某些文本编辑器存在行尾问题（对我来说也不是问题）。

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

我不知道仅将行尾留为原样还有其他问题吗？

设置autocrlf为的唯一特定原因true是：

• 避免git status将所有文件显示为modified因为将基于Unix的EOL Git存储库克隆到Windows时自动完成EOL转换（例如，参见问题83）
• 而您的编码工具某种程度上取决于文件中存在的本机 EOL样式：
  • 例如，一个代码生成器经过硬编码以检测本机EOL
  • 其他带有regexp或代码集的外部批处理（在您的仓库外部），用于检测本机EOL
  • 我相信某些Eclipse插件可以在平台上生成带有CRLF的文件，这可能是个问题。
  • 您可以使用Notepad.exe进行编码（除非您使用Windows 10 2018.09+，其中Notepad尊重检测到的EOL字符）。

除非你能看到哪些具体的治疗必须应对本土停产，你最好留下autocrlf来false（git config --global core.autocrlf false）。

请注意，此配置将是本地配置（因为该配置未从存储库推送到存储库）

如果要为所有克隆该存储库的用户使用相同的配置，请使用文件中的属性，检查“ 使用git 的最佳CRLF处理策略是什么？ ” 。text.gitattributes

例：

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

注意：从git 2.8（2016年3月）开始，合并标记将不再在CRLF文件中引入混合行结尾（LF）。
请参阅“ 让Git在其“ <<<<<<<< HEAD”合并行上使用CRLF ”

我是.NET开发人员，并且已经使用Git和Visual Studio多年了。我的强烈建议是将行结尾设置为true。并尽早在存储库的生命周期中执行此操作。

话虽这么说，我讨厌Git更改行尾。源代码控件应仅保存和检索我所做的工作，而不应对其进行修改。曾经 但是确实如此。

如果您没有将每个开发人员都设置为true，那将会发生什么，那就是一个开发人员最终将设置为true。这将开始在您的仓库中将所有文件的行尾更改为LF。并且当用户设置为false时，将其签出，Visual Studio会警告您，并要求您更改它们。您将很快发生两件事。第一，您将收到越来越多的警告，您的团队越大，您得到的越多。第二，更糟糕的是，它将显示每个修改文件的每一行都已更改（因为每一行的行尾都将由真正的家伙更改）。最终，您将无法再可靠地跟踪存储库中的更改。使每个人保持真实，而不是让每个人都虚假，要容易得多，也更清洁。事实证明，您信任的源代码控件正在做它不应该做的事情。曾经

更新2：

Xcode 9似乎具有“功能”，它将忽略文件的当前行尾，而是在将行插入文件时使用默认的行尾设置，从而导致文件的行尾混合。

我很确定Xcode 7中不存在该错误；不确定Xcode8。好消息是它似乎已在Xcode 10中修复。

就它存在的时间而言，此错误在我在问题中引用的代码库（今天使用autocrlf=false）中引起了少量的欢笑，并导致了许​​多“ EOL”提交消息，最终导致我编写了一个git pre-commithook来检查用于/防止引入混合行结尾。

更新：

注：由于注意到VonC，从Git的2.8开始，合并标记将不会推出Unix风格的行结束到Windows样式的文件。

原件：

我注意到此设置的一个小问题是，当发生合并冲突时，git添加以标记差异的行没有 Windows行尾，即使文件的其余部分也是如此，您最终可能带有混合行尾的文件，例如：

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

这不会给我们造成任何问题（我想像任何一种能够处理两种类型的行尾的工具也将处理混合的行尾-显然我们使用的所有行尾都可以），但这是需要注意的。

^*我们发现的另一件事是，当git diff用于查看具有Windows行尾的文件的更改时，已添加的行将显示其回车符，因此：

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{*它并不是真正值得称呼的问题：“问题”。}