Can git-svn be made to handle CRLF like native subversion clients?

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

Enchase

Well I'm truly baffled. I started trying to fix this again but the slow speed of the svn clone on windows made me start doing it on Linux. I brought to repo over to Windows then disabled CRLF and did a reset --hard. Now I seem to have a working git-svn repository that behaves correctly... Now to figure out what steps are actually needed to make this work all the time... Hopefully this really did work and I wont run into problems as I start using it. – Enchase

Answer 1

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).

Gokey

That's quit a clever idea. I'll experiment with this. – Enchase

In the end I've ended up using a totally local git repository and doing updates (to the git master branch) and commits to the remote repo using SVN. I don't get a very useful local history but I do get feature branches and other git niceness this way. Hopefully in the future I'll have some time to try and fix what's actually wrong with git-svn. – Enchase

Answer 2

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.

Gokey

Sadly half decent editors doesn't include all of the ones that are needed to build the project. Stupid, but it's an immovable object for the time being. I did experiment with different settings before the clone including doing the clone on a Linux machine. I still couldn't get things into a state where either git or the build tools didn't cause too many things to get marked as changed when only line endings were affected. I'll give you an upvote though, as it seems that this would work for most people. – Enchase

In that case, convert all line-endings to CRLF, and commit to the master svn repository. – Gokey

Apparently, that wont be allowed. Sigh. – Enchase

This is really a valid solution for working with git-svn, if the svn repositories stores the files with CRLFs (developtment unter windows). – Imhoff

Answer 3

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.

Muskeg

This seems to be my best option for now. I can use the output from "git status" to list modified files and run those through a script to "fix" them. Setting "core.fileMode = false" and a "git reset --hard" was needed to get things back to how they really should have been. Kludgy, but it seems to have done the trick. – Enchase

Actually, this still seems to upset git's diff. I'm going back to my original less attractive plan of just putting my working copy into a git repository. – Enchase

Answer 4

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.)

Murray

But doesn't that destroy git annotate history? I have a similar problem to the OP, I believe, and manually "fixing" files after the clone just means I'm writing all over the history of those files, rendering it useless. – Meanly

Answer 5

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.

Matthia

Answer 6

Another good conversations here about core.autocrlf.

Cini

I don't think this helps with the git-svn problem. There's something silly going on inside there that makes getting a usable checkout out Windows a pain. – Enchase