4

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?

cleek
  • 874
  • 8
  • 15
  • 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. – sabgenton Dec 19 '12 at 22:36
  • @sabgenton, from the [man page](http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html),"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. – cleek Dec 31 '12 at 21:26
  • possible duplicate of [git line endings : renormalize does not seem to checkout the right line endings](http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings) – Mr_and_Mrs_D Jul 05 '13 at 21:37

2 Answers2

13

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.

Duncan Smart
  • 31,172
  • 10
  • 68
  • 70
cleek
  • 874
  • 8
  • 15
  • 2
    Thank you for confirming this, I thought I was going crazy for a while. I've filed [a bug](http://github.com/msysgit/msysgit/issues/97). – bricelam Feb 06 '13 at 18:57
  • @Brice: Thanks for logging that bug. I just was about to post the same question. – Daniel Hilgarth Feb 25 '13 at 12:52
  • I was the one who made the comment after asking here - see the answer [here](http://stackoverflow.com/a/13552603/281545) for a link to a bug report/fix. Really glad it draws some attention it's very annoying :) – Mr_and_Mrs_D Apr 16 '13 at 01:33
  • 1
    This bug has finally been fixed in [Git for Windows 1.8.4](http://code.google.com/p/msysgit/downloads/list?can=1&q=1.8.4). – sschuberth Sep 17 '13 at 08:11
-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.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 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. – orad Mar 17 '13 at 05:54
  • 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. – Frank Seide MSFT Oct 08 '18 at 20:05