.gitattributes with core.autocrlf unset

Question

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

* text=auto
*.txt text

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?

Mako

I would have thought your second line is defeated in which case you should swap the lines around.. I saw someone on SO say you can't set something a second time in .gitattributes and in your example you've actually set *.txt files to text=auto on the FIRST line. – Burundi

@sabgenton, from the man page,"When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute." Also, you may want to reference reference the link in my answer below. – Mako

possible duplicate of git line endings : renormalize does not seem to checkout the right line endings – Blus

Answer 1

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.

Mako

Thank you for confirming this, I thought I was going crazy for a while. I've filed a bug. – Untenable

@Brice: Thanks for logging that bug. I just was about to post the same question. – Brandie

I was the one who made the comment after asking here - see the answer here for a link to a bug report/fix. Really glad it draws some attention it's very annoying :) – Blus

This bug has finally been fixed in Git for Windows 1.8.4. – Gradient

Answer 2

you need to set core.autocrlf to input. On windows set it to true.

If you are not sharing x-platform, then set it to false and forget about the attributes altogether.

Valida

Bad suggestion on second line. You don't know if you would decide to share with x-platform later so it's wise to config it right from the beginning. – Amyamyas

Adam is correct. autocrlf should simply never be used. All reasonable text editors today know to handle both conventions and keep them. We have had numerous problems with this feature, including that it tried to convert LF to CRLF in UTF-16 files, corrupting them. – Alissaalistair