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

Question

为什么我要在Git中使用core.autocrlf=true？我有一个Git存储库，它可以从Windows和OSX访问，而且我知道它已经包含了一些带有CRLF行尾的文件。据我所知，处理这个问题的方法有两种：集core.autocrlf到false到处都是，按照指示执行这里(在GitHub的帮助页上呼应)将存储库转换为只包含LF行尾，然后设置core.autocrlf到true在Windows和input在OSX上，这样做的问题是，如果存储库中有任何二进制文件，那么：他们会堕落的。我的存储库可能包含这样的文件。在gitproperties中未正确标记为二进制，并且恰巧同时包含CRLF和LFS，那我为什么不直接关掉Git的行结束转换呢？网上有很多关于core.autocrlf关闭导致问题，但很少专一到目前为止，我发现的唯一问题是kDiff3不能处理CRLF的结尾(对我来说不是问题)，而且一些文本编辑器有行尾问题(对我来说也不是问题)。存储库是我的公司内部的，所以我不需要担心与具有不同的autocrlf设置或行结束需求的人共享它。还有其他问题吗？我还没有意识到。

Answer 1

更新:

注：正如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

_{*这并不是真正值得使用的术语：“问题”。}