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.

Answer 2

I don't know much about git on Windows, but...

Appears to me that git is converting the return format to match that of the running platform (Windows). CRLF is the default return format in Windows, while LF is the default return format for most other OSes.

Chances are, the return format will be adjusted properly when the code is moved to another system. I also reckon git is smart enough to keep binary files intact rather than trying to convert LFs to CRLFs in, say, JPEGs.

In summary, you probably don't need to fret too much over this conversion. However, if you go to archive your project as a tarball, fellow coders would probably appreciate having LF line terminators rather than CRLF. Depending on how much you care (and depending on you not using Notepad), you might want to set git to use LF returns if you can :)

Appendix: CR is ASCII code 13, LF is ASCII code 10. Thus, CRLF is two bytes, while LF is one.

Answer 3

Removing the below from the ~/.gitattributes file

* text=auto

will prevent git from checking line-endings in the first-place.

Answer 4

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

Do this on a separate commit or git might still see whole files as modified when you make a single change (depending on if you have changed autocrlf option)

This one really works. Git will respect the line endings in mixed line ending projects and not warning you about them.

Answer 5

1. Open the file in the Notepad++.
2. Go to Edit/EOL Conversion.
3. Click to the Windows Format.
4. Save the file.

Answer 6

git config core.autocrlf false