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

Question

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

我有一个Git存储库，它可以从Windows和OSX访问，而且我知道它已经包含了一些带有CRLF行尾的文件。据我所知，处理这个问题的方法有两种：

1. 集core.autocrlf到false到处都是，

2. 按照指示执行这里(在GitHub的帮助页上呼应)将存储库转换为只包含LF行尾，然后设置core.autocrlf到true在Windows和input在OSX上，这样做的问题是，如果存储库中有任何二进制文件，那么：

   他们会堕落的。我的存储库可能包含这样的文件。

1. 在gitproperties中未正确标记为二进制，并且
2. 恰巧同时包含CRLF和LFS，

那我为什么不直接关掉Git的行结束转换呢？网上有很多关于core.autocrlf关闭导致问题，但很少专一到目前为止，我发现的唯一问题是kDiff3不能处理CRLF的结尾(对我来说不是问题)，而且一些文本编辑器有行尾问题(对我来说也不是问题)。

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

还有其他问题吗？我还没有意识到。

Answer 1

更新:注：正如Vonc所指出的，从Git 2.8开始，合并标记将要不将Unix样式的行尾引入到Windows样式的文件中.原版:我在这个设置中注意到的一个小问题是，当出现合并冲突时，git会添加一行来标记差异。不拥有Windows行尾，即使文件的其余部分也是如此，并且您可以一个带有混合行尾的文件结束，例如：//&nbsp;Some&nbsp;code<CR><LF> <<<<<<<&nbsp;Updated&nbsp;upstream<LF> //&nbsp;Change&nbsp;A<CR><LF> =======<LF> //&nbsp;Change&nbsp;B<CR><LF> >>>>>>>&nbsp;Stashed&nbsp;changes<LF> //&nbsp;More&nbsp;code<CR><LF>这不会给我们带来任何问题(我认为任何可以处理两种类型的行尾的工具也会处理混合行尾-当然是我们使用的所有那些)，但这是需要注意的。另一件事*我们发现，当我们使用git diff若要查看对具有Windows行尾的文件的更改，已添加的行将显示它们的回车情况，因此：&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Not&nbsp;changed +&nbsp;&nbsp;&nbsp;//&nbsp;New&nbsp;line&nbsp;added&nbsp;in^M +^M &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Not&nbsp;changed &nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Not&nbsp;changed*这并不是真正值得使用的术语：“问题”。