Cleanly Migrate Your Subversion Repository To a GIT Repository

So you're ready to ride the GIT train eh? But what about all those projects in your subversion repository? Sure you could just use git-svn but what you really want is to cleanly move that repository and all its history to a nice new GIT repository.

Luckily it's not that hard. For this example I'm going to use my_blog as the application name you're porting to a GIT repository. We're basically going to just initialize a new GIT repository, point it at your SVN repository, and suck in your code and history while remapping the users to GIT users. We'll then just clone THAT repository to have a clean GIT repository free of SVN clutter.

The first thing we need to do is create a users file that maps all your SVN users to your GIT users. Just make a file on your Desktop named 'users.txt'. Map the users using this format:

jmaddox = Jon Maddox <jon@gmail.com>
bigpappa = Brian Biggs <bigpappa@gmail.com>

Simple. Now here are the commands you'll run. I'll explain them below.

mkdir my_blog_tmp
cd my_blog_tmp
git-svn init http://code.yoursite.net/my_blog/trunk/ --no-metadata
git config svn.authorsfile ~/Desktop/users.txt
git-svn fetch

The first two are self explanatory, we're making a new directory for the temporary repository. The second command initializes the directory as a git-svn hybrid thing and points the origin at your SVN repository. The flag, --no-metadata, tells GIT to leave all the SVN details behind (not the commit log). The fourth command tells GIT to remap all the SVN users to GIT users when it sucks down the source and history. The last command actually does the fetching.

Ok, so now after a few LONG minutes, your source is all there. Do a git log to see that your users have been mapped. Sweet!

Now you just have one last step. You need to clone this repository. Why do we do this? When doing a normal git clone it will take everything we want from the temporary repository, while leaving behind all the SVN cruft that was there to support the git-svn stuff.

git clone my_blog_tmp my_blog

Boom! You're done. Now you have a super clean GIT repository all ready to use.

Popularity: 51% [?]

You can skip to the end and leave a response. Pinging is currently not allowed.

30 Thoughts

  1. What to do in the case that you're pulling from a Google code repository where the 1st commit has no author. When I run git-svn fetch, I get a complaint: Author: (no author) not defined in ~/users.txt file

  2. You could always define 'no author' i guess. see if that solves it.

  3. Nope. I tried: empty string, "no author", "(no author)". None work. Is it possible to skip the initial revision? Or perhaps pull it down w/o the user mapping and define it later?

  4. Any thoughts on migrating with plugins installed through piston? How does one keep the metadata it uses and pass it on to a suitable replacement? What is the best piston alternative for git? I tried braid but that did not work out on that occasion.

  5. I'm not real sure, I dont really use piston. As for an alternative, there is Giston.

  6. Or Braid.

  7. Thanks for the guide, I just split my huge personal subversion repository into separate git repositories. With a little googling I also figure out how to push them to my web-server.

  8. Be sure to check out GitHub for some sweet GIT hosting action

  9. Thanks to you, sir, every Subversion repo I've maintained on my system is now gone and replaced with Git. My deepest appreciation.

  10. @Rob: you can tell git svn fetch to select a set of revisions instead of starting from the first.

    Look in the git svn man page.
    > -r , --revision
    something like -r 2:HEAD could work I'm guessing.

  11. @Rob: (no author) = First Last worked for me.

  12. Probably you want to delete the remote branch after cloning:

    rm -R my_blog_tmp
    cd my_blog
    git remote rm origin

    Bernhard Hartleb -
  13. Thanks for the guide

  14. Great guide. You may be interested in how I compress and clean a migrated repository even further:

    http://www.bytetrap.com/blog/2008/06/07/slimming-down-git-repository/

  15. You should also mention that you can import the branches if they follow a standard Subversion format. Look at the man page for git-svn for details.

  16. This worked for me (svn 1.4 -> github.com). Many thanks

  17. thanks for the info :)

  18. Rob,

    The git alternative to piston is now piston 2 (or at least 1.9.3 from source). It handles a mixture of git and svn plugins.

    You can use it if your own repository is either git or svn based, too.

    For how to grab it from source, check http://technicalpickles.com/posts/piston-and-git-for-the-win

    Cheers,
    Walter

  19. When I run "git-svn fetch" I get:
    "No such file or directory: Error in child process: exec of 'C:Program FilesPuTTYplink.exe' failed: No such file or directory at /bin/git-svn line 1383"
    Any ideas? For some reason is removed the slashes in the plink path.

  20. Great tutorial. Just worked with my company svn! Thanks!

  21. A quick thank-you for sharing this. I'm in the middle of the fetch stage and it's working like a charm.

  22. Thanks and congratulations!

  23. I think people should play more chess, and that dogs should be trained as leek farmers.

  24. If you notice that your vendor/plugins directory is missing, your svn is likely using svn:externals. This threw me for a bit because git-svn doesn't warn you. I didn't find any magical solution, but I've posted notes with links to various options here: http://www.ultrasaurus.com/sarahblog/2009/02/moving-from-svn-to-git/

  25. Thanks for writing this, I looked around quite a bit for something so simple.

  26. The simplicity of this made my day.

  27. Well, I've got the following question.

    I've decided to convert my project on SourceForge--originally we were using SVN and now want to move to GIT.

    So I've checked out my project from SVN located at sourceforge. I've did the local conversion to GIT by your guide--everything went fine.

    How to put my new GIT repo back to SF now, with all revisions and history?

  28. PRICELESS!!!
    We just converted eleven of our repositories using the simple instructions on your post.
    Thank you!

  29. Shameless plug: http://github.com/nothingmuch/git-svn-abandon is little more thorough than svn2git when it comes to handling branches, cleaning up svk commit messages, etc.

    There are also instructions on how to recover merge metadata by hand in the README.

  30. bah, i meant handling tags, not branches. =P

Share Your Thoughts?

Please excuse my captcha. But the internets require it these days. Comment triage isn’t billable.