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

Question

行结束转换是如何与git核心一起工作的。我读过很多关于堆栈溢出的不同问题和答案吉特关于核心设置有效。从我所读到的，这就是我的理解：Unix和MacOSX(前置OSX使用CR)客户端使用LF行尾。Windows客户端使用CRLF行尾。当core.autocrlf在客户端上设置为true时，git存储库总是以LF行结束格式存储文件，客户端上的文件中的行尾在签出/提交时来回转换，这些客户端使用非LF行结束，无论客户端上的行尾文件采用何种格式(这与Tim Clem的定义不一致-请参见下面的更新)。下面是一个矩阵，它试图为core.autocrlf的“输入”和“false”设置记录相同的内容，其中我不确定行结束转换行为。我的问题是：问号应该是什么？这个矩阵对“非问号”是正确的吗？我将更新答案中的问号，因为似乎已经形成了共识。                       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

1. 从存储库签出的文本文件

   LF

   字符归一化为

   CRLF

   在工作树中；包含

   CRLF

   在存储库中不会被触摸
2. 只有

   LF

   存储库中的字符，将从

   CRLF

   到

   LF

   当提交回存储库时。包含

   CRLF

   在存储库中将不受影响地提交。

• core.autocrlf = input

1. 从存储库签出的文本文件将在工作树中保留原始的EOL字符。
2. 在工作树中的文本文件

   CRLF

   字符归一化为

   LF

   当提交回存储库时。

• core.autocrlf = false

1. core.eol

   在工作树的文本文件中口述EOL字符。

2. core.eol = native

   默认情况下，这意味着WindowsEOLs是

   CRLF

   和*nix EOLs是

   LF

   在工作的树上。
3. 储存库

   gitattributes

   设置确定提交到存储库的EOL字符规范化(默认为规范化为

   LF

   )。

我只是最近才研究过这个问题，我也发现情况非常复杂。这个core.eol设置确实有助于阐明GIT如何处理EOL字符。

Answer 2

混合平台项目中的EOLs问题使我的生活很长一段时间都很悲惨。当已经存在具有不同和混合EOLs的文件时，通常会出现这些问题。已经在回购中。这意味着：

1. 回购程序可能有不同的文件和不同的EOLs。
2. 回购中的某些文件可能具有混合的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种情况下发生转换：

1. core.autocrlf

   是

   true 和

2. 回购中的文件具有

   LF

   EOL。

对我来说最令人惊讶的是，我怀疑，造成许多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.