title: Why should I use core.autocrlf=true in Git?
body: <p>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:</p>
  
  <ol>
  <li><p>Set <code>core.autocrlf</code> to <code>false</code> everywhere,</p></li>
  <li><p>Follow the instructions <a href="https://stackoverflow.com/questions/1510798/trying-to-fix-line-endings-with-git-filter-branch-but-having-no-luck/1511273#1511273">here</a> (echoed on GitHub's help pages) to convert the repository to contain only LF line-endings, and thereafter set <code>core.autocrlf</code> to <code>true</code> on Windows and <code>input</code> on OS X. The problem with doing this is that if I have any binary files in the repository that: </p>
  
  <ol>
  <li>are not correctly marked as binary in gitattributes, and </li>
  <li>happen to contain both CRLFs and LFs,</li>
  </ol>
  
  <p>they will be corrupted. It is possible my repository contains such files.</p></li>
  </ol>
  
  <p>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 <code>core.autocrlf</code> switched off causing problems, but very few <em>specific</em> 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).</p>
  
  <p>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.</p>
  
  <p>Are there any other problems with just leaving line-endings as-is that I am unaware of?</p>