Git core.autocrlf settings poll results

The results from last week’s poll are in! And they couldn’t be more (less) clear:


A highly unscientific poll shows an even split between true and false, with a minority choosing the other two options. So that settles it!

What’s interesting is that everyone except the GitHub employees on Twitter were adamant in choosing “false”, while the GitHub employees were adamant for “true”:



It’s still so, so silly that this is something we have to worry about. For more reading on the issue, check out:

What will I set? I’m going to try out the .gitattributes way of doing things and just how it goes. But I think we can all agree that core.autocrlf is not something we should have to worry about, up front, for Git users on Windows.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in git. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I’ve always heard that autocrlf was a response by Linux guys to keep the Windows and Mac contributors from messing up their line endings.  

    So I get the reason you want autocrlf for mix-platform teams.

    Other than that, it makes no sense to me why you’d want that except as a sort of anal-retentive/OCD keep-everything-consistent measure.

    I guess that describes the Github guys, huh? ;)

    • Arioch The

      GitHub position has clear explanation. Their pull-request routines are very sensitive to CRLF issues and turn single line change into “delete all file and replace it” patch. Basically, w/o autocrlf their pull requests are defunct unless all the developers adheres to upstream’s strict rules on manually setting the option. Which you can hardly expect on DVCS and on newcomers, unless that option would be cloned during all the sources at the initial tabula rasa checkout.

  • Anonymous

    This is what it comes down to:
    - non-Windows users want Windows users to use “true”, so they never have to see crlf endings
    - Windows users want to use “false”, because it doesn’t make sense to have your SCM modify your files

    Non-Windows users need to realize that a large majority of Windows users will NEVER contribute to a non-Windows project. That gap will only grow as Git becomes more accessible to Windows users, and is promoted more by OSS efforts at Microsoft. The sensible default for all of those users is to keep Windows line endings. The miniscule number of Windows users that contribute to a non-Windows project can figure out how to change their configuration.

    • JD

      bash scripts choke on windows line endings.
      Cygwin users run bash scripts on windows.
      Source control shouldn’t change the source code, because it ‘thinks’ CRLF is your OS’s setting. Line endings aren’t even PER OS.

  • Carter Jim

    I set it to false, and force every IDE/text editor to use LF.

  • greggwon

    The problem is that people who need to work together on an existing system who switch between users with different IDEs or different settings in those IDEs end up with varied line endings. GIT should never change line endings when it “pulls” a file into your repo, plain and simple. I will do that or I will pick standards to do that.

    The even more prevalent issue is that GITHUB desktop is not using “git diff -w” on text files to detect differences, create differences or otherwise show what has changed, Users of GITHUB desktop should be able to set the arguments to “diff” which are used to show changes and/or mark files as changed in the “Changes” tab.

    Not being able to switch branches when GIT has altered a file line endings is a huge time waster and overall, the people making decisions about how all of this work are either extremely inexperienced or are not listening to the real stories of how stupid this behavior actually is, considering what it doesn’t accomplish.