为什么我要用核心。在Git中为true ?

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

  1. 将所有地方的core.autocrlf设置为false，

  2. 遵循指令在这里(在GitHub的帮助页面上显示)将存储库转换为只包含LF行结束符，然后在Windows上将core.autocrlf设置为true，在OS x上设置input。这样做的问题是，如果我在存储库中有任何二进制文件，则:

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

    他们会被腐化。有可能我的存储库中包含这样的文件

那么为什么我不应该关闭Git的行结束转换呢?网上有很多关于关闭core.autocrlf会导致问题的模糊警告，但很少有具体的警告;到目前为止，我唯一发现的是kdiff3不能处理CRLF结尾(对我来说不是问题)，以及一些文本编辑器有行结束问题(对我来说也不是问题)。

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

还有什么我不知道的问题吗?

392703 次浏览
小开
最佳答案

将autocrlf设置为true的唯一具体原因是:

  • 避免git status显示你所有的文件为modified，因为当克隆一个基于unix的EOL Git回购到Windows时，会自动进行EOL转换(例如，参见发行83)
  • 而且你的编码工具在某种程度上取决于你的文件中出现的本地的 EOL样式:

    除非你能看到必须处理原生EOL的特定治疗方法，否则最好使用将__ABC0留给false (git config --global core.autocrlf false)。

    注意，该配置将是当地的配置(因为配置不会从repo推到repo)

    如果你想为克隆该repo的所有用户设置相同的配置，请检出"git最好的CRLF处理策略是什么?"，使用< >强.gitattributes < /强>文件中的text属性。

    例子:

    *.vcproj    text eol=crlf
*.sh        text eol=lf
    注意:从git 2.8(2016年3月)开始，合并标记将不再在CRLF文件中引入混合行结束(LF) 参见“让Git在“<<<<<<< <<<”合并线”< / p >
小开

更新2:

Xcode 9似乎有一个“特性”，它将忽略文件当前的行结束符，而只是使用默认的行结束符设置在插入到文件中时，导致文件的行结束符混合。

我很确定这个bug在Xcode 7中不存在;不确定Xcode 8。好消息是这个问题在Xcode 10中得到了修复。

在它存在的时候，这个错误在我在问题中提到的代码库中引起了少量的搞笑(直到今天使用autocrlf=false)，并导致了许多“EOL”提交消息，最终我写了一个git pre-commit钩子来检查/防止引入混合行结束符。

更新:

注意:VonC指出，从Git 2.8开始，合并标记将不是引入unix风格的行结束符到windows风格的文件。

原始:

我在这个设置中注意到的一个小问题是，当存在合并冲突时，git添加来标记差异的行不具有Windows行结束符，即使文件的其余部分具有Windows行结束符，并且你可以最终得到一个具有混合行结束符的文件，例如:

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

这不会给我们带来任何问题(我想任何可以处理这两种类型的行结束符的工具也会合理地处理混合行结束符——当然我们使用的所有工具都是这样)，但是需要注意这一点。

我们发现的另一件事__abc1是，当使用git diff查看对具有Windows行结束符的文件的更改时，已添加的行将显示其回车符，从而:

    // Not changed


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

*它并不真正配得上“问题”这个词。

小开

我是一个。net开发人员，已经使用Git和Visual Studio很多年了。我强烈建议将行结束符设置为true。并且在您的Repository生命周期内尽早完成它。

也就是说，我讨厌Git改变我的行结束。源码控制应该只保存和检索我所做的工作，它不应该修改它。永远。但确实如此。

如果不是每个开发人员都设为真，最终会有一个开发人员设为真。这将开始改变行结束你的所有文件在你的回购。当用户设置为假检出时，Visual Studio会警告你，并要求你更改它们。有两件事会很快发生。第一，你会得到越来越多的警告，你的团队越大，你得到的警告就越多。第二，更糟糕的是，它将显示每个被修改文件的每一行都被更改了(因为每一行的行结束符将由true guy更改)。最终，您将无法再可靠地跟踪回购中的更改。让每个人都保持真实比让每个人都保持虚假容易得多，也干净得多。可怕的是，你所信任的源代码控制系统正在做一些它不应该做的事情。永远。

小开

给我。

编辑.gitattributes文件。

添加

*.dll binary

然后一切都很顺利。

小开

我正在GitHub上工作，我发现这篇文章很有帮助。

它描述了git的配置和设置。gitattributes文件。

小开

在我们的项目中，我们声明了将selff设置为输入值的必要性。以下是你可能会感兴趣的原因:

  • 您的项目在Linux/Unix环境中运行，开发人员在Windows中编写代码。在推送期间，CRLF会自动转换为LF，因此你只需要在Unix服务器上签出Git repo，一切都会开箱运行。
  • 有时开发人员使用WinSCP手动将配置从Windows计算机上传到服务器。这会导致Unix机器上的CRLF行结束和应用程序启动失败。“input"Value部分地消除了这种情况的数量

我们不久前面临的问题是:

  • 如果在DEV的机器上，行结束符被设置为CR(而不是CRLF)，那么在推送过程中，它们不会被转换为LF，而是在GIT存储库中保持CR。是否彻底检查行尾

提交答案