Can git-svn be made to handle CRLF like native sub

Question

I have a subversion repository hosted on Linux but only ever accessed via windows clients as it's for the source of a large Windows application.

It would be awesome if I could work on this repository using git-svn (provided by msysgit).

I'm having a heck of a time trying to get the repository to not get itself in a jam over the windows style line endings.

After svn clone a checkout of the git repository with:

• core.autocrlf = true shows modifications to any file which actually does use LF in the repository.
• core.autocrlf = input shows modifications to any file which actually does use LF in the repository.
• core.autocrlf = false shows modifications to everything.

What's the best option here? Should I use core.autocrlf = true and commit the LF to CRLF changes for affected files?

I'm very close to throwing in the towel and just putting my Subversion working copy into a git repository. This would be a poor solution but would at least allow local branches and stashes. It will obviously become a huge pain to keep adding files when they are added to subversion.

EDIT: For those who are interested. git-svn is a royal pain if you are on Windows. hasen j's answer below is probably the right one but I can't follow his advice without attracting the ire of the other developers in my team.

I'm essentially abandoning this question since it isn't going to lead to a reasonable outcome. Hopefully the next Google Summer of Code will attract someone who wants to pickup their "Proper git-svn support on Windows" project. See http://git.or.cz/gitwiki/SoC2009Ideas#Propergit-svnsupportonWindows

Answer 1

I usually clean up my git-svn clone with git-filter-branch over recode dos..ascii -f. (This has also helped for latin1..utf8 conversion, as well.)

Answer 2

I had a similar problem. To solve it, after the git-svn clone, I applied unix2dos to all files because, in my case, all files in the SVN repo used CRLF. So, I guess you should try the CRLF-LF conversion manually right after git-svn.

Answer 3

Normally, you'd want to set the core.autocrlf option like so:

git config core.autocrlf true

But according to this article, it looks like it doesn't play well with git-svn specifically. It might be worth a shot in a safe second copy of your SVN repository to see if it works.

Answer 4

Do yourself a favor and don't mess with line-endings, keep them as-is. set autocrlf to false.

Any half-decent text editor in windows should be able to handle unix-style line endings.

core.autocrlf = false shows modifications to everything.

I think that if you only do that after the fact, it won't do you any good.

You have to delete this repository, set autocrlf to false, and then do the clone.

Answer 5

Another good conversations here about core.autocrlf.

Answer 6

Since my other answer doesn't apply well to you, here's another way to deal with the situation:

Use both svn and git; in the same working directory.

You'll mainly be working with git, pulling from the upstream repository, making local changes, local branches, etc; everything that you normally do when you work on a local git project.

Then, when you want to commit to the central svn repo, use the svn client.

I had some experience doing this, only I wouldn't do an svn commit, but instead create a patch with svn diff and submit it (since I had no commit access anyway).