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

Ric*_*ich 272 git line-endings

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

  1. 设置core.autocrlffalse无处不在,

  2. 按照指示在这里(回荡在GitHub上的帮助页)到存储库转换为只包含LF行结束,然后设置core.autocrlftrue在Windows和input在OS X上有这样做的问题是,如果我有仓库中任何二进制文件那:

    1. 在gitattributes中未正确标记为二进制文件,并且
    2. 碰巧包含CRLF和LF,

    他们会被腐化.我的存储库可能包含这些文件.

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

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

是否有任何其他问题只是留下我不知道的行结尾?

Von*_*onC 203

设置唯一的具体原因autocrlftrue有:

  • 避免git status显示所有文件,modified因为在将基于Unix的EOL Git存储库克隆到Windows时会自动执行EOL转换(例如,请参见问题83)
  • 并且您的编码工具以某种方式依赖于文件中存在的本机 EOL样式:

除非你能看到哪些具体的治疗必须应对本土停产,你是关好留下autocrlffalse.

请注意,此配置将是本地配置(因为配置不会从repo推送到repo)

如果你想为克隆该repo的所有用户提供相同的配置,请使用文件中的属性查看" 使用git 的最佳git config --global core.autocrlf false处理策略是什么? " .CRLFtext


注意:启动git 2.8(2016年3月),合并标记将不再在CRLF文件中引入混合行结尾(LF).
请参阅" 让Git在其上使用CRLF"<<<<<<< HEAD"合并线 "

  • 我肯定会使用`false`,我从来不是后台发生的自动或魔术事件的忠实粉丝.到处都使用`\n`和`UTF-8`,你会没事的.如果某些坚果头不明白有惯例和规则并忘记使用`UTF-8`或`\n`,那么有人会手动转换它们并拍打他的脸. (47认同)
  • @VonC:我不认为这个答案是对的.在Windows上使用core.autocrlf = true按预期工作.来自repo的所有文件(在此方案中应该具有LF行结尾)在结账时转换为CRLF行结尾到Windows PC.从Windows PC提交时,所有文件都转换回LF行结尾.遇到麻烦的方法是最初检查到具有错误core.autocrlf设置的Windows PC(这完全太容易了). (14认同)
  • @VonC谢谢!这让我更有信心使用`autocrlf = false`对我来说是安全的.出于兴趣,你知道为什么即使你将autocrlf设置为false,git仍会进行eol转换吗? (5认同)
  • @ Pauld'Aoust我仍然希望在`.gitattributes`文件中通过`core.eol`属性指定需要CRLF的文件类型,而不是使用这个全局`core.autocrlf`设置,该设置不加选择地应用于*all*文件. (5认同)
  • @Michael所以在这种情况下,如果我的某些工具/编辑器会被行结尾混淆,那么在我的场景中不使用`core.autocrlf = false`的唯一原因是什么? (3认同)
  • 不知何故,在hg docs http://mercurial.selenic.com/wiki/EolExtension中找到了如何(不)使用autocrlf的最佳解释(注意"最后的手段"警告) (3认同)
  • 它对于源文件可能期望的项目变得更加重要并创建CRLF行结尾,但是某些文件的检出要求您保留行结尾,如bash脚本.我正在开发一个针对Windows开发的软件,但也有我们想要不受影响的bash脚本,但可以进行编辑和版本控制.这些混合行结束意味着我们要么需要autocrlf = false,要么需要为特定文件创建.gitattributes. (2认同)

JGT*_*lor 33

我是.NET开发人员,多年来一直使用Git和Visual Studio.我的强烈建议是设定行结束为真.并在存储库的生命周期中尽早完成.

话虽如此,我讨厌Git改变我的行结尾.源代码控制应该只保存和检索我做的工作,它不应该修改它.永远.但确实如此.

如果你没有让每个开发人员都设置为true会发生什么,那么ONE开发人员最终会设置为true.这将开始在您的仓库中将所有文件的行结尾更改为LF.当用户设置为false检查时,Visual Studio会警告您,并要求您更改它们.你会很快发生两件事.一,你会得到越来越多的警告,你的团队越大,得到的就越多.第二个也是最糟糕的是,它会显示每个修改过的文件的每一行都被更改(因为每一行的行结尾都会被真正的人改变).最终,您将无法再可靠地跟踪回购中的更改.让每个人都保持真实,比试图让每个人都虚假更容易和更清洁.尽管你可靠的源代码控制正在做一些不应该做的事情,但这很可怕.永远.

  • 正是我的想法.它不是源代码控制的工作,因为它喜欢乱码代码文件.行结尾应该只是编辑工具的一个问题,仅此而已. (7认同)
  • 如果您的项目仅限Windows,则没有问题.但是,如果您或您的同事在*nix平台上工作,那么您的"强烈建议"将导致问题.尝试运行bash,perl或python脚本,shebang以`\ r \n`结尾,你会看到. (5认同)
  • 您描述的情况不是GIT的问题,将设置设置为FALSE,因为它通常应该是,它已经消失了.Instad,这是团队工作中的一个问题.什么意思"最终一个开发人员设置'真实'"?**为什么**你会首先允许它们?当你设置它们来访问git repo时,就像你不允许用不同的lang污染某些区域一样(所以任何人都可以读取它),或者就像你保持分支/合并/ rebase/etc一样政策,他们应该得到一个明确的规则:设置正确的crlf. (4认同)
  • 像这样的帖子提醒我,我们必须将行结尾视为代码文化中的一等公民。 (3认同)

Ric*_*ich 12

更新:

注:由于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>
Run Code Online (Sandbox Code Playgroud)

这并没有给我们带来任何问题(我想任何可以处理这两种类型的行结尾的工具也会对混合行结尾做出明智的处理 - 当然我们使用的都是这样),但这是需要注意的事情.

另一件事*我们发现,是使用时git diff查看更改了Windows行结束,已添加施展回车,这样行的文件:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed
Run Code Online (Sandbox Code Playgroud)

*这个词并不值得:"问题".

  • 注意当Visual Studio遇到这样的文件时,它会为您标准化行尾.选择Windows行结尾或选择*not*来规范行结尾工作正常(因为VS仍然正确显示它,一旦解决了冲突,有问题的行将被删除). (2认同)
  • 不幸的是,公司版本控制纳粹不同意它(合并冲突标记上的LF)不是问题. (2认同)