git replacing LF with CRLF

Question

Running git on a Windows XP machine, using bash. I exported my project from SVN, and then cloned a bare repository.

I then pasted the export into the bare repositori

Answer 1

I had this problem too.

SVN doesn't do any line ending conversion, so files are committed with CRLF line endings intact. If you then use git-svn to put the project into git then the CRLF endings persist across into the git repository, which is not the state git expects to find itself in - the default being to only have unix/linux (LF) line endings checked in.

When you then check out the files on windows, the autocrlf conversion leaves the files intact (as they already have the correct endings for the current platform), however the process that decides whether there is a difference with the checked in files performs the reverse conversion before comparing, resulting in comparing what it thinks is an LF in the checked out file with an unexpected CRLF in the repository.

As far as I can see your choices are:

1. Re-import your code into a new git repository without using git-svn, this will mean line endings are converted in the intial git commit --all
2. Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style
3. Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again.
4. Rewrite your repository's history so that the original commit no longer contains the CRLF that git wasn't expecting. (The usual caveats about history rewriting apply)

---

Footnote: if you choose option #2 then my experience is that some of the ancillary tools (rebase, patch etc) do not cope with CRLF files and you will end up sooner or later with files with a mix of CRLF and LF (inconsistent line endings). I know of no way of getting the best of both.