行结束转换是如何与git核心一起工作的。

Question

行结束转换是如何与git核心一起工作的。

我读过很多关于堆栈溢出的不同问题和答案吉特关于核心设置有效。

从我所读到的，这就是我的理解：

Unix和MacOSX(前置OSX使用CR)客户端使用LF行尾。
Windows客户端使用CRLF行尾。

当core.autocrlf在客户端上设置为true时，git存储库总是以LF行结束格式存储文件，客户端上的文件中的行尾在签出/提交时来回转换，这些客户端使用非LF行结束，无论客户端上的行尾文件采用何种格式(这与Tim Clem的定义不一致-请参见下面的更新)。

下面是一个矩阵，它试图为core.autocrlf的“输入”和“false”设置记录相同的内容，其中我不确定行结束转换行为。

我的问题是：

1. 问号应该是什么？

2. 这个矩阵对“非问号”是正确的吗？

我将更新答案中的问号，因为似乎已经形成了共识。

                       core.autocrlf value
            true            input              false
----------------------------------------------------------
commit   |  convert           ?                  ?
new      |  to LF      (convert to LF?)   (no conversion?)

commit   |  convert to        ?                 no 
existing |  LF         (convert to LF?)     conversion

checkout |  convert to        ?                 no
existing |  CRLF       (no conversion?)     conversion

我并不是真的在寻找各种设置的正反两方面的意见。我只是在寻找数据，它清楚地说明了如何期望git对这三个设置中的每一个进行操作。

--

阅读后蒂姆·克莱姆的文章在注释中由JJD链接，我修改了上表中“未知”值中的一些值，并更改了“签出现有的true以转换为CRLF，而不是转换为Client”。以下是他给出的定义，这些定义比我在其他地方看到的任何东西都更清晰：

core.autocrlf=false

这是默认情况，但大多数人都被鼓励立即改变这种情况。使用false的结果是，Git永远不会处理文件中的行尾。你可以签入的文件与LF或CRLF或CR或随机混合的这三个和Git不在乎。这可能会使差异更难阅读和合并更加困难。大多数在Unix/Linux环境中工作的人使用这个值是因为他们没有CRLF问题，而且每当文件被写入对象数据库或写入工作目录时，他们不需要Git做额外的工作。

core.autocrlf=true

这意味着Git将处理所有文本文件，并确保在将该文件写入对象数据库时用LF替换，并在写入工作目录时将所有LF转换回CRLF。这是在Windows上推荐的设置，因为它确保您的存储库可以在其他平台上使用，同时将CRLF保留在您的工作目录中。

core.autocrlf=输入

这意味着Git将处理所有文本文件，并确保在将该文件写入对象数据库时用LF替换CRLF。然而，它不会适得其反。当您从对象数据库中读取文件并将它们写入工作目录时，它们仍然有LFS来表示行尾。此设置通常用于Unix/Linux/OSX，以防止CRLFs被写入存储库。这样做的想法是，如果您从Web浏览器粘贴代码，并意外地将CRLF放入您的文件中，则Git将确保在写入对象数据库时将它们替换为LFS。

Tim的文章很棒，我唯一能想到的就是他认为存储库是LF格式的，这不一定是正确的，特别是对于只适用于Windows的项目。

将Tim的文章与JmLane迄今投票最多的答案进行比较，显示出对真实和输入设置的完美一致，以及对错误设置的不同意见。

Answer 1

最好的解释是core.autocrlf作品可在基属性手册页，在text属性部分这就是为什么core.autocrlf目前看来是有效的(或者至少从我所知的1.7.2版本开始)：core.autocrlf = true从存储库签出的文本文件LF字符归一化为CRLF在工作树中；包含CRLF在存储库中不会被触摸只有LF存储库中的字符，将从CRLF到LF当提交回存储库时。包含CRLF在存储库中将不受影响地提交。core.autocrlf = input从存储库签出的文本文件将在工作树中保留原始的EOL字符。在工作树中的文本文件CRLF字符归一化为LF当提交回存储库时。core.autocrlf = falsecore.eol在工作树的文本文件中口述EOL字符。core.eol = native默认情况下，这意味着WindowsEOLs是CRLF和*nix EOLs是LF在工作的树上。储存库gitattributes设置确定提交到存储库的EOL字符规范化(默认为规范化为LF)。我只是最近才研究过这个问题，我也发现情况非常复杂。这个core.eol设置确实有助于阐明GIT如何处理EOL字符。

Answer 2

混合平台项目中的EOLs问题使我的生活很长一段时间都很悲惨。当已经存在具有不同和混合EOLs的文件时，通常会出现这些问题。已经在回购中。这意味着：回购程序可能有不同的文件和不同的EOLs。回购中的某些文件可能具有混合的EOL，例如CRLF和LF在同一个文件里。这不是问题所在，但它确实发生了。我在Windows上对各种模式及其组合进行了一些转换测试。下面是我在一个稍微修改过的表格中得到的信息：                 | Resulting conversion when       | Resulting conversion when                   | committing files with various   | checking out FROM repo -                   | EOLs INTO repo and              | with mixed files in it and                  |  core.autocrlf value:           | core.autocrlf value:            -------------------------------------------------------------------------------- File             | true       | input      | false | true       | input | false -------------------------------------------------------------------------------- Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is如您所见，在提交时有2种情况发生转换(左3列)。在其他情况下，文件是按原样提交的。在签出时(3列右列)，只有1种情况下发生转换：core.autocrlf是true 和回购中的文件具有LFEOL。对我来说最令人惊讶的是，我怀疑，造成许多EOL问题的原因是没有混合EOL的配置。CRLF+LF恢复正常。还请注意，“旧”MacEOLsCR只是从来没有改变过。这意味着，如果写得不好的EOL转换脚本试图将混合结束文件转换为CRLFS+LFS，只是通过转换LFS到CRLF，则它将以混合模式将该文件保留为“孤独”。CR在任何地方CRLF转换成CRCRLF.这样，git就不会转换任何东西，即使是在true模式，而EOL破坏仍在继续。这实际上发生在我身上，并且严重地破坏了我的文件，因为一些编辑器和编译器(例如VS 2010)不喜欢MacEOLs。我想真正解决这些问题的唯一方法就是偶尔通过签出input或false模式，运行适当的规范化并重新提交已更改的文件(如果有的话)。在Windows上，可能继续使用core.autocrlf true.