通过`.gitattributes`强制使用`core.autocrlf=input`

Question

有没有一种方法可以在 .gitattributes 中强制执行 core.autocrlf=input，以便将该策略传播给我的同事？

详细来说，我想在 add 时转换为 lf，并在 checkout 时保持 asis 不变。

问题在于，在 .gitattributes 中，text 和 eol 都无法满足我的需求，因为 eol 有三个可接受的值:

1. lf
2. crlf
3. native

理想情况下，我希望我的 .gitattributes 文件看起来像这样：

* text eol=asis

- laertis

---

你想在代码库中使用什么行尾？LF？还是保留工作树中原来的行尾？ - bk2204

你要找的设置是这个：* text=auto eol=lf。 - Aaron Franke

Answer 1

"as is" 在工作树中的确切含义不太清楚。如果您希望Git在存储库中存储LF行尾，并让用户根据其平台和/或设置决定工作树中需要什么，则使用以下内容：

* text

这将强制进行行结束符转换，Git 将会在版本库中将文件转换为 LF 并在检出时遵守用户首选的行结束符。如果您的文件不都是文本文件（即，您有图像或其他二进制文件），并且希望 Git 进行猜测，则可以使用以下命令：

* text=auto

请注意，如LoopInFool所述，这不会导致已经是CRLF的文件被转换，因此您需要确保您的文件已经在存储库中是LF，或明确将这些文件类型列为文本（例如*.c text）。 core.autocrlf=input的行为是在添加到存储库时强制转换为LF，并在检出时不执行任何转换；也就是说，始终使用LF结尾，而不考虑用户的设置。如果这是您想要的行为，则可以使用以下方法：

* eol=lf

请注意，设置eol实际上设置了text属性，所以您不应该在任何二进制文件上设置它。

如果您希望Git在检出时匹配已经存在于工作树中的行尾（例如通过读取文件），那么它不会这样做。Git总是基于配置进行换行转换，而不考虑已有的内容，因此用户必须以某种方式指示其首选项或接受平台默认行为。

此外，即使Git在添加时忽略这些更改（比如因为您只更改了行尾），Git始终将文件大小的任何修改视为git status中的修改，这也是无法避免的。

如果您想要完全不同的东西，请稍微详细说明您想要的行为，我会提供更多详细信息。

- bk2204

Answer 2

“core.autocrlf=input”的最接近的替代方案是在“.gitattributes”文件中使用“text=auto”。这指定它们为文本文件，因此新文件将使用LF行尾放入仓库。根据gitattributes文档的说明，通过设置“text=auto”，如果文件已经以CRLF提交，则不进行转换。我们最近将一个Mercurial仓库转换为Git。Mercurial不进行eol转换，因此在转换后，许多文件已经具有CRLF。对于这些文件扩展名，设置“text=auto”允许新文件仍然规范化为LF，但不会触及现有文件，并且不会在当前目录中显示它们已被修改。

- LoopinFool

Answer 3

详细来说，我的要求是在提交时将换行符转换为lf，在检出时保持不变。Git不会在提交时转换，而是在git add时进行转换。（更准确地说，它在将对象复制到仓库并生成哈希值的操作上进行转换——但对于大多数情况来说，这只是git add。）此时应用任何“clean”过滤器并执行输入端EOL操作。（同样，当从仓库复制到工作树时，输出端“smudge”过滤器和EOL操作发生在大多数情况下是git checkout和git reset --hard。）

根据 gitattributes文档，设置eol=lf：

强制Git在签入时将行尾标准化为LF，并在检出文件时防止转换为CRLF。

因此，虽然我实际上没有测试过这一点，但听起来* eol=lf正是你想要的。请注意，这与core.eol不同，后者的行为就像你在问题中描述的那样；这仅适用于.gitattributes设置，适用于匹配名称模式的文件。

- torek

---

好的...之前我向提问者建议过使用 eol=lf，但是并没有成功：https://dev59.com/BXA75IYBdhLWcg3wm6Uj#8kQcoYgBc1ULPQZFRrBw - VonC

顺便提一下，这方面的文档似乎正在逐渐改善，但仍然很混乱，有时代码中的某些内容似乎与文档中的某些内容不匹配。因此，您可能还需要指定特定的Git版本。我怀疑Windows Git团队有时也会因为这些问题而与非Windows团队发生争执 :-) - torek

文档并不糟糕，但至少令人困惑。我正在使用 git 2.8.3 under cygwin 和 git 1.8.3.1 under CentOS 7，我已经检查过两者都在 .gitattributes 中使用 eol 而不是向后兼容的 crlf。 @torek 另一个支持你在文档中的声明的事情是，eol=lf 的向后兼容是 crlf=input。然而，在实践中，我发现 autocrlf=input 可以让我得到一个干净的 _clone_，而 eol=lf 在克隆后会有 end-of-line 冲突。 - laertis

另外，假设 eol=lf 解决了我的第一个问题，即检出时对行尾不进行任何操作，那么第二个问题呢？它要求在“添加”时将所有内容转换为换行符。我认为尽管没有明确说明，eol=lf 暗示左侧部分是文本，这又意味着应在远程上将其转换为 lf。 - laertis

让我们在聊天中继续这个讨论。 - laertis