.gitattributes：text=auto是否仍然使用core.autocrlf来检测行尾符？

Question

.gitattributes：text=auto是否仍然使用core.autocrlf来检测行尾符？

5

通过在.gitattributes文件中添加条目。

 * text=auto

当检出文本文件时，使用哪种行分隔符？文档指出：

字符串值“auto”

当文本设置为“auto”时，该路径被标记为自动换行符转换。如果Git判断内容是文本，则在签入时将其行尾转换为LF。当文件已经以CRLF提交时，则不进行转换。

未指定

如果未指定文本属性，则Git使用core.autocrlf配置变量来确定是否应将文件转换。

这对我来说意味着，在text=auto的情况下，core.autocrlf无关紧要。我的理解正确吗？

- Thomas S.

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- torek · Accepted Answer

这对我来说听起来好像是说，在.gitattributes中有text=auto时，core.autocrlf在配置中就不重要了。我说得对吗？

大部分是对的。现在git config文档对于core.autocrlf说：

将此变量设置为“true”与将所有文件的text属性设置为“auto”和将core.eol设置为“crlf”相同。...可以将此变量设置为“input”，在这种情况下不执行输出转换。

令人困惑的是，就在几行之前，git config文档本身就说到了core.eol：

为那些在core.autocrlf为false时设置了text属性的文件设置工作目录中要使用的行结束类型[而我没有告诉你它何时设置为true或input]...有关换行符转换的更多信息，请参见gitattributes(5)。

（粗体和括号内的文字属于我自己添加的）。然而，core.autocrlf的描述则涉及到有效地设置core.eol，那么当core.autocrlf设置为true或input且core.eol设置为crlf时会发生什么呢？

如果我们查看gitattributes文档，就会发现这个短语：

使用单个文件的eol属性和所有文本文件的core.eol配置变量来控制工作目录中使用的行结束样式。请注意，core.autocrlf会覆盖core.eol。

因此，如果你没有设置 core.autocrlf，这也不会覆盖 core.eol。这意味着不管你为core.eol选择什么，都适用于默认设置。但是，如果你设置了core.autocrlf，无论你为core.eol选择什么设置，都将被忽略！

Git内部的实际源代码非常复杂（并在多年中经历了数次更改）。但是有一些东西对所有 Git 变体来说都是正确的：

转换通常只发生在两个地方：从索引到工作树的文件复制（“输出”阶段）或从工作树到索引的文件复制（“输入”阶段）。输出端复制发生在git checkout和git checkout-index期间，它们都从索引复制文件到工作树。输入端复制发生在git add期间，它会将文件从工作树复制到索引。
被视为“二进制”的文件不会被修改。被视为“文本”的文件则可能被修改。

因此，* text=auto 表示所有文件都可能被修改，并且 core.autocrlf 也有相同的效果。但是，应用了什么修改呢？这一部分比较棘手。假设上面两个配置文档部分的引用对于所有 Git 版本来说都是正确的：

如果针对任何特定路径，你有一个具有特定eol=的.gitattributes设置，则core.eol设置就无关紧要了。但是，这与是否在text=中有.gitattributes设置是无关的。
因此，无论在哪里忘记了还有一个特定的 eol=设置，你有效的core.eol设置控制那些转换。

因此，由于core.autocrlf可以更改有效的core.eol设置，并且您可能会忽略为某些text文件设置特定的设置，因此设置 core.autocrlf 可以像将core.eol设置更改为crlf一样，即使您已经对所有文件设置了text = auto。(如果将core.autocrlf设置为input会发生什么具体情况需要进行仔细测试。)

¹这里使用了单词normally，因为它谈到了文件在进出Git时的转换位置。但是对于某些操作，例如针对工作树的git diff或启用“规范化”的git merge，Git必须进行“虚拟签入”或“虚拟签入和签出”，在这种情况下，Git会进行一些额外的转换。不幸的是，这正是Git内部实际代码如此复杂的原因。