Question: I have a Git repository that is accessed from both Windows and OS X, and that I know already contains some files with CRLF line-endings. As far as I can tell, there are two ways to deal with this:

1. Set `core.autocrlf` to `false` everywhere,
2. Follow the instructions [here](https://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273) (echoed on GitHub's help pages) to convert the repository to contain only LF line-endings, and thereafter set `core.autocrlf` to `true` on Windows and `input` on OS X. The problem with doing this is that if I have any binary files in the repository that: 

	1. are not correctly marked as binary in gitattributes, and
	2. happen to contain both CRLFs and LFs,they will be corrupted. It is possible my repository contains such files.

So why shouldn't I just turn off Git's line-ending conversion? There are a lot of vague warnings on the web about having `core.autocrlf` switched off causing problems, but very few *specific* ones; the only that I've found so far are that kdiff3 cannot handle CRLF endings (not a problem for me), and that some text editors have line-ending issues (also not a problem for me).

The repository is internal to my company, and so I don't need to worry about sharing it with people with different autocrlf settings or line-ending requirements.

Are there any other problems with just leaving line-endings as-is that I am unaware of?

Answer: 
I am a .NET developer and have used Git and Visual Studio for years. My strong recommendation is to set line endings to true. And do it as early as you can in the lifetime of your Repository.

That being said, I HATE that Git changes my line endings. Source control should only save and retrieve the work I do, it should NOT modify it. Ever. But it does.

What will happen if you don't have every developer set to true, is ONE developer eventually will set to true. This will begin to change the line endings of all of your files to LF in your repo. And when users set to false check those out, Visual Studio will warn you, and ask you to change them. You will have 2 things happen very quickly. One, you will get more and more of those warnings, the bigger your team the more you get. The second, and worse thing, is that it will show that every line of every modified file was changed(because the line endings of every line will be changed by the true guy). Eventually, you won't be able to track changes in your repo reliably anymore. It is MUCH easier and cleaner to make everyone keep to true than to try to keep everyone false. As horrible as it is to live with the fact that your trusted source control is doing something it should not. Ever.
In our project we declared necessity of setting autocrlf to **input** value. Here is why you may be interested in this:

* Your project runs in Linux/Unix environment and developers are writing code in Windows. During push CRLF is transformed into LF automatically, thus you just need to checkout Git repo on Unix server and everything will be good out of the box.
* Sometimes developers upload configuration from Windows machines to servers manually using WinSCP. This leads to CRLF line endings on Unix machines and failed app starts. "input" value partially eliminates the number of such cases

The issues we faced not long ago:

* If the line endings are set to CR (not CRLF) on DEV's machine, during push they won't be transformed to LF and will stay CR in GIT repository. Do checks of line-endings thoroughly