Line endings
---
When Windows/Linux/OS X developers work together, things can get a bit tricky,
because Windows uses a different encoding for line endings (CRLF) than
Unix-flavoured systems do (LF). So, depending on the editor(s) you use, you
will usually start to aggregate a weird mix of different line endings and
troublesome merges whenever someone changes them around. This is clearly not an
awesome thing to have to deal with.

### The traditional solution

Before git 1.7.2, you could use the `core.autocrlf` setting (and a few related
ones) to fix files, but with a chance of some files getting broken (because
git has to apply heuristics in order to tell text files from binary files)...
so I'm not going to talk about that solution.

### The current best solution

git 1.7.2 introduced the `core.eol` setting and automatic conversion of files
that are marked as text files in `.gitattributes`. Msysgit, the recommended
Windows port of git, automatically has `core.eol` set to the right value for
standard Windows tool. So, typically all that's left is creating a proper
`.gitattributes` file (which you can then add to the repository so that
everything works correctly for everyone by default). Here's an example:

    *.c text
    README text
    /foo/bar/hello text

That's all there is to it. From now on, files will automatically be checked
out with your system's native encoding for line endings, and new commits will
contain a normalized version (LF encoding).

### Loose ends: old, broken files

If you already have files with CRLF encoding in your repository, you'll find
that sooner or later someone will commit changes to it and then all line
endings will be converted to LF in the repository.

If you had files with incorrect line endings in your working tree before you
created a proper .gitattributes files, you can either throw away all
uncommitted changes using `git reset --hard` or use a separate tool (perhaps
your editor) to convert the line endings to your system's native format. Some
editors do this automatically.

### A word about Cygwin

Cygwin pretends to be a Unix environment, so its version of git will use LF
line encodings. Don't use Windowsy editors together with Cygwin and line
ending normalization... or, if you do, be sure to set `core.eol` to `crlf`.