.gitattributes with core.autocrlf unset答案

【问题标题】：.gitattributes with core.autocrlf unset.gitattributes with core.autocrlf unset
【发布时间】：2012-11-22 13:37:57
【问题描述】：

我的存储库中有一个 .gitattributes 文件，看起来像这样

* text=auto
*.txt text

我在存储库、全局和系统设置中取消了 core.autocrlf。根据 gitattributes 的文档，我的理解是，存储库中名称以 .txt 结尾的所有文件都应使用本机行结尾签出。不过，我看到的是 .txt 文件总是有 LF 作为行尾，即使在 Windows 上也是如此。鉴于此配置，为什么 Windows 上的行结尾不是 CRLF？

【问题讨论】：

我原以为你的第二行被打败了，在这种情况下你应该换行。我看到有人说你不能在 .gitattributes 和你的例子中再次设置您实际上已在第一行将 *.txt 文件设置为 text=auto。
@sabgenton，来自man page，“当多个模式与路径匹配时，后面的行会覆盖前面的行。这种覆盖是按属性完成的。”另外，您可能需要参考下面我的答案中的链接。
git line endings : renormalize does not seem to checkout the right line endings的可能重复

标签： git core.autocrlf gitattributes

【解决方案1】：

问题是在处理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/ 的 cmets 让我得到了这个答案。

【讨论】：

感谢您确认这一点，我以为我疯了一段时间。我已经提交了a bug。
@Brice：感谢您记录该错误。我刚要发布同样的问题。
我是在这里询问后发表评论的人 - 请参阅答案 here 以获取错误报告/修复的链接。真的很高兴它引起了一些注意，这很烦人:)
这个bug终于在Git for Windows 1.8.4修复了。

【解决方案2】：

您需要将 core.autocrlf 设置为输入。在 Windows 上将其设置为 true。

如果您不共享 x-platform，则将其设置为 false 并完全忘记属性。

【讨论】：

第二行的错误建议。您不知道以后是否会决定与 x-platform 共享，因此明智的做法是从一开始就对其进行配置。
亚当是正确的。 autocrlf 根本不应该被使用。今天所有合理的文本编辑器都知道处理这两种约定并保持它们。我们在使用此功能时遇到了许多问题，包括它试图将 UTF-16 文件中的 LF 转换为 CRLF，从而损坏了它们。