It's better to store Git files with Unix line endings (LF) and not Windows endings (CRLF). The convention makes it easier for others to use your code and is what the Git implementation was designed to work with. Note that, despite what many websites say, git's core.autocrlf setting is a bit outdated and it's better to use a .gitattributes file.
Using .gitattributes with * text=auto is perfect for new files (Git internally stores text files with LF, but the working copy will have appropriate newlines for the platform). But when importing from svn, my old svn repos had kept all of the CRLF endings, and doing a git svn import even on a posix system imported the files with CRLF. Adding the svn:eol-style=native property to all text files in the svn repo could work, as would importing into git and then doing one large commit to renormalize line endings, but these would show up in revision history, which I didn't want.
The following worked:
(open terminal in Linux.)
(install dos2unix if needed.)
git svn clone -s --no-metadata file:///path/to/svn/repo/newgit
cd newgit
(rewrite history and change newlines)
(dos2unix, at least modern versions, skips binary files)
git filter-branch -f --tree-filter 'find . -path './.git' -prune -o -type f -exec dos2unix \{} \;' HEAD
(wait as history is rewritten. loops through every revision.)
(now, create a new repo that is not attached to svn.)
mkdir ../newgit2
cd ../newgit2
git clone file:///path/to/newgit
(cd to this new repo)
(create a file named .gitattributes file with the contents "* text=auto")
git add .gitattributes
git commit
(done. if this repo is cloned on a Windows system, )
(there will be CRLF in the working copy and LF internally,)
(as Git expects.)References:
http://maururu.net/2009/svn-to-git-take-2/
Stack Overflow