.gitattributes 中的“* text=auto eol=lf”和“* text eol=lf”有什么区别？答案

【问题标题】：What's the difference between "* text=auto eol=lf" and "* text eol=lf" in .gitattributes?.gitattributes 中的“* text=auto eol=lf”和“* text eol=lf”有什么区别？
【发布时间】：2019-07-02 18:09:03
【问题描述】：

这与这个问题非常相似： What is the differrence between `* text=auto` and `* text eol=lf` in .gitattributes?

但我特别问为什么我应该使用* text=auto eol=lf 而不是* text eol=lf，反之亦然？

据我了解，eol 会覆盖 text 设置，那么使用前者有什么意义呢？有区别吗？如果是这样 - 如何？

我现在正在阅读很多网站和 Stack Overflow 问题/答案 - 但我仍然完全糊涂。尤其是当我看到这种变化时：https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248

我发现更改的措辞很难读懂，以至于我现在一点也不聪明。有人可以解释一下吗？

【问题讨论】：

标签： git gitattributes

【解决方案1】：

Git 中有代码可以检测文件是文本文件还是二进制文件。

如果一个文件的前面有很多零（ASCII NUL）字节，则该文件被视为二进制文件。其他一些二进制模式也是如此。

Git 默认使用此代码来决定是否在git diff 检测到某个文件中的某些更改时向您显示差异。如果文件看起来是二进制文件，Git 会说“二进制文件不同”（默认情况下，你可以让它打印一个可用的差异，例如，git format-patch 强制执行该行为）。否则，该文件似乎是文本，所以你得到一个常规的差异。

Git 也在.gitattributes 中将此代码用于text=auto，但不用于text-without-=auto。所以：

* text=auto eol=<whatever>

告诉 Git：每次从索引中提取文件到工作树时，将检测代码应用于文件。如果检测代码声称该文件是文本文件，则应用行尾转换，同时将文件的冻干副本从索引重新水化为工作树中的可用形式。如果检测代码声称该文件是二进制文件，请不要理会它。¹

相比之下，* text eol=<whatever> 告诉 Git：每次将文件重新水化到工作树中时，应用行尾转换。 Git 2.10 版本之前的错误是 * text=auto不小心指的是* text 而不是* text=auto。

¹由于文本检测有时（尽管不是那么频繁）在（例如）.jpg 图像文件上出错，因此依赖 @987654333 是不明智的@。但它大部分时间都有效。

【讨论】：

我终于明白为什么需要这么长的解释了，因为幕后发生了很多事情。如果您不仔细阅读文档（就像我没有仔细阅读的那样），那么很容易不知所措并感到困惑。感谢您的澄清！
剩下的问题是什么时候应该使用一个而不是另一个。我目前的理解是，这一切都取决于模式。 * 当然范围很广，因此您也更有可能捕获一些二进制文件。在这种情况下，您可能希望拥有text=auto 以防止二进制文件被规范化。在我的特殊情况下，几乎没有二进制文件，所以我可以使用* text eol=lf，我可以使用*.resource binary 将任何非文本文件标记为二进制文件（在我的情况下为 *.resource）。但在大多数情况下* text=auto eol=lf 是要走的路。你同意吗？
@Semmel：嗯...我避免使用 WIndows，因此不需要或不希望我的 VCS 弄乱我的文件，这意味着我不希望或不需要任何 i> 这些。但是，当使用在 Windows 系统上使用的存储库（例如 Git 的 Git 存储库）时，我观察到其他人显式调用每个文件扩展名和/或路径：他们永远不会离开它让 Git 猜测文件是文本还是二进制文件。
这是一个很好的观点。我有一个存储库，它一直是 LF - 但偶尔会出现 CRLF。这是 * text=auto eol=lf 可能可行的唯一情况 - 在所有其他设置中，我也会选择明确声明所有内容。