Migrating SVN to Git... Standard github instructions result in no files?

When I followed the standard github instructions to migrate svn to git using “git-svn”.  When I tried:

$ git svn clone  SVN_REPO_URL LOCAL_DIR

I’d appear like it was checking out files… it’d chug away for about 1000 commits and then just stop with no error messages.  When i’d CD to my new git repo… there would be no files other then the .git database. 

I’m not sure why this was… perhaps it’s cause our SVN repos are really old.  I don’t really exactly know.  But, here’s the procedure that worked for us.  This guide was originally written for internal use so substitute “alertustech” for your username and “allert-eth” for your repo name.  One other note to point out is our repos didn’t have tags or branches that we cared about.  So, we omitted the -s or —stdlayout switches.

1) It’s assumed you already have local user configured, SSH keys generated and uploaded, etc.

2) Set up a local authors.txt file (in my case S:\GitRepos\authors.txt)

git config svn.authorsfile /S/GitRepos/authors.txt 
(NOTE: make this an absolute path, not a relative one)
Note2: If you get an error such as “could not lock config file /path/to/file/.gitconfig” alternatively you can append —authors-file=/path/to/file on the git svn fetch

mkdir allert-eth-tmp

cd allert-eth-tmp

git svn init SVN_REPO_URL —no-metadata (should be two — in front of no-metadata)

git svn fetch

At this point you should check your directory to see if files are there or not. If there are (other then the .git) proceed to the next section. In my case I found that the git fetch was timing out after about 1000 commits for some reason. I had a similar issue with svnsync it’s something apache related. So, what I had to do was do another fetch. But this time with the —revision=###:HEAD (where ### was the last commit processed in the previous command.

git svn fetch —revision=[NUM]:HEAD

After it completes again, check to see if files exist now by doing an ls. If they still don’t repeat the git fetch command this time incrementing the revision argument to the commit you got to this time around

now, according to this site, you have a working (local) git repo, but there’s still SVN cruft left (not sure exactly.) so you then do:

cd .. (in my case back to S:\GitRepos)

git clone allert-eth-tmp allert-eth (makes a new dir allert-eth automatically)

and now you are almost ready to push it to github but you’ll probably hit one more error, so let’s try:

cd allert-eth

git remote add origin git@github.com:alertustech/allert-eth-fw.git 

At this point I got an error: “fatal: remote origin already exists”. I found a marginally-helpful stackoverflow post from which I determined the proper sequence of commands to fix this, as follows

git remote rm origin

(now retry) git-remote add origin git@github.com:alertustech/allert-eth-fw.git (and you

should have no issues - the problem was that there was already a destination defined for “origin” and it was set to the local filesystem location of the repo, not sure how/why this came about, likely a consequence of git svn)

And finally, 

git push -u origin master 

I gather that “origin” and “master” are names for locations, or copies in this case - so what you’re doing here is calling “origin” the github copy, and “master” your existing copy, so pushing the master to the origin, and future clean checkouts will have the github copy as “origin”.  At this point all the info should show up on the github page and you can begin using the repo as normal.

Special thanks to Phil Anderson for writing up these instructions.

UPDATE: Those instructions are a little complicated… If you don’t have a big repo, you can probably get away with this:

$ mkdir PCB
$ git svn init https://SVN_URL_TO_THE_FOLDER_IMPORTING —no-metadata
$ git svn fetch —authors-file=/d/authors.txt
$ git remote add origin https://github.com/yourhandle/yourrepo.git
$ git push -u origin master

Blake Robertson | 2 Comments | Share Article Permalink

tagged Git GitHub