Monday, January 28, 2013

Moving a svn with CRLF line-endings to git

In case this helps someone else out there,

Moving a svn repo with Windows line endings to git

Background: It's best to store Git files with Unix line endings (LF) and not Windows endings (CRLF). This convention makes it easier for others to use your code and is what the Git implementation was designed to work with. Note that git's core.autocrlf setting is deprecated and it's better to specify lines in a .gitattributes file.

I wanted to set .gitattributes with * text=auto, which means that Git will internally store text files with LF, but the working copy will have appropriate newlines for the platform. Git will also automatically distinguish between text and binary files.

svn maintains the CRLF endings, and doing a git svn import even on a posix system imports 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 it's not there.)
git svn clone -s --no-metadata file:///path/to/svn/repo/newgit
cd newgit
# rewrite history and change newlines
# dos2unix, at least recently, 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 isn't attached to svn.
mkdir ../newgit2
cd ../newgit2
git clone file:///path/to/newgit
(cd to this new repo)
(add the .gitattributes file specifying * 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.

I wonder if someone should go through Stack Overflow and note the outdated information about core.autocrlf.

References:
http://maururu.net/2009/svn-to-git-take-2/
Stack overflow

No comments: