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: 
**Update 2**:

Xcode 9 appears to have a "feature" where it will ignore the file's current line endings, and instead just use your default line-ending setting when inserting lines into a file, resulting in files with mixed line endings.

I'm pretty sure this bug didn't exist in Xcode 7; not sure about Xcode 8. The good news is that it appears to be fixed in Xcode 10.

For the time it existed, this bug caused a small amount of hilarity in the codebase I refer to in the question (which to this day uses `autocrlf=false`), and led to many "EOL" commit messages and eventually to my writing a git `pre-commit` hook to check for/prevent introducing mixed line endings.

**Update**:

Note: As noted by VonC, starting from Git 2.8, merge markers [will *not* introduce Unix-style line-endings to a Windows-style file](https://stackoverflow.com/a/35474954/6309). 

**Original**:

One little hiccup that I've noticed with this setup is that when there are merge conflicts, the lines git adds to mark up the differences do *not* have Windows line-endings, even when the rest of the file does, and you can end up with a file with mixed line endings, e.g.:

```
// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

```

This doesn't cause us any problems (I imagine any tool that can handle both types of line-endings will also deal sensible with mixed line-endings--certainly all the ones we use do), but it's something to be aware of.

The other thing\* we've found, is that when using `git diff` to view changes to a file that has Windows line-endings, lines that have been added display their carriage returns, thus:

```
    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

```

\* It doesn't really merit the term: "issue".
For me.

Edit .gitattributes file.

add

```
*.dll binary

```

Then everything goes well.