.gitattributes未设置core.autocrlf

Question

.gitattributes未设置core.autocrlf

4

我在我的代码库中有一个.gitattributes文件，它看起来像这样：

* text=auto
*.txt text

我在仓库、全局和系统设置中取消了core.autocrlf。根据gitattributes的文档，我的理解是仓库中所有文件名以.txt结尾的文件都应该使用本地换行符进行检出。但是，我看到的是，即使在Windows上，.txt文件的换行符始终为LF。鉴于这种配置，为什么在Windows上的换行符不是CRLF呢？

- cleek

我本以为你的第二行被打败了，所以你应该交换这两行。我在 Stack Overflow 上看到有人说你不能在 .gitattributes 中第二次设置某个东西，在你的例子中，你实际上是在第一行将 *.txt 文件设置为 text=auto。 - sabgenton

@sabgenton，在man页面中指出，“当一个路径匹配多个模式时，后面的行将覆盖前面的行。这种覆盖是针对每个属性进行的。”此外，您可能还想参考下面我的答案中的链接。 - cleek

可能是重复的问题：git行尾：renormalize似乎没有检出正确的行尾。 - Mr_and_Mrs_D

2个回答

-2

你需要将core.autocrlf设置为input。在Windows上将其设置为true。

如果你不需要跨平台共享，那么将其设置为false并忘记这些属性。

- Adam Dymitruk

第二行建议不好。你不知道以后是否会决定与跨平台共享，所以最好从一开始就正确配置它。 - orad

Adam是正确的。autocrlf根本不应该被使用。现今所有合理的文本编辑器都知道如何处理这两种约定并保持它们。我们曾经遇到过许多问题，包括它试图在UTF-16文件中将LF转换为CRLF，从而破坏了它们。 - Frank Seide MSFT

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

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

- cleek · Accepted Answer

问题在于core.eol的处理中存在一个错误。gitattributes文档指出，如果未定义，则会使用native，这应该默认为系统适当的行尾（对于Windows：CRLF，对于Unix：LF）。然而，在我的系统上，将core.eol取消定义或将其设置为native始终导致行尾为LF。因此，解决方法是在Windows上显式地将core.eol设置为crlf。 http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ 上的评论指引我得到了这个答案。