.gitattributes与core.autocrlf未设置 [英] .gitattributes with core.autocrlf unset

问题描述

我的资源库中有一个.gitattributes文件，它看起来像这样。

I have a .gitattributes file in my repository that looks like this

* text=auto
*.txt text

我已在存储库，全局和系统设置中取消设置core.autocrlf。根据gitattributes的文档，我的理解是，存储库中名称以.txt结尾的所有文件都应该使用本机行结尾进行检出。但是，我所看到的是，.txt文件始终具有换行结尾的LF，即使在Windows上也是如此。给定这种配置，为什么Windows上的行结束CRLF？

I have unset core.autocrlf in the repository, global, and system settings. My understanding, based on the documentation for gitattributes, is that all files in the repository whose names end with .txt should be checked out with the native line endings. What I'm seeing, though, is that the .txt files always have LF for line endings, even on Windows. Given this configuration, why aren't the line endings CRLF on Windows?

推荐答案

问题是，处理core.eol。 gitattributes的文档说，如果未设置，那么将使用native，默认为系统的适当行结尾（CRLF for Windows，unix的LF），但是不要将core.eol设置为未设置，或将其设置为本机系统总是以LF结束行结束。那么答案就是明确地将core.eol设置为在Windows上的crlf。 http://adaptivepatchwork.com/2012 / 03/01 /介绍你的行结束/ 引导我回答这个问题。

The problem is that there is a bug in the handling of core.eol. Documentation for gitattributes says that if it is unset then native will be used, which should default to the proper line endings for your system (CRLF for Windows, LF for unix), however leaving core.eol unset or setting it to native on my system always results in LF for line endings. The answer, then, is to set core.eol to crlf on Windows explicitly. The comments at http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ led me to this answer.

这篇关于.gitattributes与core.autocrlf未设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！