Comments on: Git core.autocrlf settings poll results

By: Arioch The

Arioch The — Wed, 13 Feb 2013 20:48:00 +0000

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.

By: JD

JD — Thu, 18 Oct 2012 00:01:00 +0000

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.

By: Anonymous

Anonymous — Fri, 09 Mar 2012 02:18:00 +0000

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.

By: Chad Myers

Chad Myers — Fri, 09 Mar 2012 00:42:00 +0000

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?