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.
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.
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).
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.
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