".gitattributes"文件中的"eol=lf"和"text"有什么区别？"

Question

".gitattributes"文件中的"eol=lf"和"text"有什么区别？"

git

12

根据.gitattributes文档，text属性可启用行尾规范化：

text

将text属性设置到文件路径，可以启用行尾规范化并标记该路径为文本文件。行尾转换不需要猜测内容类型。

同样的文档还提到，eol=lf也可以规范化换行符：

eol

此属性将特定的行尾风格设置为在工作目录中使用。它启用了行尾规范化而无需任何内容检查，实际上设置了text属性。

给出的示例将它们混合在同一个文件中似乎意味着它们之间存在一些（或许微妙的）差异：

*.txt       text
*.vcproj    eol=crlf
*.sh        eol=lf
*.jpg       -text

同时，似乎没有一个明确的声明说明它们是相同的，或者text是eol=lf的简写—尽管似乎是这样。我能够找到的与此类似的最接近的声明就是我上面引用的那句话，它说" effectively setting the text attribute"。但是，单词 effectively 似乎略微有所保留，好像它并没有实际设置文本属性，而只是更或多或少地设置它，或者具有几乎相同的效果。

究竟这两者有什么不同？（还是text只是常见用例的简写？）在一个.gitattributes文件中混合使用这两个是否有任何原因？

或者： text需要Git猜测你需要哪种类型的换行符，而eol（显然）指定了吗？

- iconoclast

我认为 eol=lf 明确防止文件在检出时转换为 CRLF，而 text 可能会根据 Git 系统配置引入 CRLF。 - miqh

据我所知，来自这里，Git配置系统仅适用于未指定文件类型的情况：“如果文件未指定，则Git将回退到core.autocrlf设置，并且您将回到旧系统。” - iconoclast

1个回答

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

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

- Robert Claypool · Accepted Answer

eol 告诉 Git 在你的工作目录中使用哪种换行符，并且还为仓库中的文件启用 LF 标准化。此设置适用于特定路径，因此在示例中我将使用 *.txt：

*.txt eol=crlf 告诉 Git（1）在 checkin 时将行尾标准化为 LF 并（2）在检出文件时将其转换为 CRLF。
*.txt eol=lf 告诉 Git（1）在 checkin 时将行尾标准化为 LF 并（2）在检出文件时防止将其转换为 CRLF。

请注意，这两个设置都会在 checkin 时将行尾标准化为 LF！这有效地设置了text 属性，因为text会执行相同的操作。

由于这些设置仅适用于未来的更改，所以需要其他步骤来更新已经 checkin 的文件。

还有一件事...要小心，只在与文本文件匹配的路径上设置 eol。它会启用标准化而不进行任何内容检查，但是二进制文件不应该标准化。根据您的路径，您可能需要显式地排除某些文件类型：

# Disable eol normalization for these types:
*.png -text
*.jpg -text
*.ttf -text