We are currently considering the option of migrating from svn to git for all the benefits that git offers. We are currently worried about losing history and looking into the issue. We would like to know if anyone had other problems when they migrated from svn to git.
5 Answers
There shouldn't be any problems converting from svn to git regarding losing history. That's the main purpose of revision control software anyway, to keep track of history.
The number one rule is of course: always back up your repositories before converting them and do several test runs until you feel confident enough to do it in a production environment.
A major difference is the way externals in Subversion behave compared to git submodules. See:
- Why are git submodules incompatible with svn externals?
- How do I adapt my svn:externals strategy to git submodules?
- Git submodule tutorial
Also, expect to spend some time on supporting the users. Git is a different beast and some accustomed svn users can find that it is a bit unintuitive to use.
Edit: Git has built in support for importing and working with svn repositories, using git-svn.
-
3The number one rule is of course: use git-svn for import SVN into Git repo, **not convert** – Lazy Badger Jan 26 '12 at 10:13
-
Very good point indeed. I'm editing my answer to reflect that. – Sundae Jan 26 '12 at 10:16
-
@Lazy Badger, what is your distinction between "import" and "convert?" The standard way to "convert" an svn repo to a git repo does indeed use git-svn. – ebneter Jan 26 '12 at 19:05
-
Thanks Sundae. Your answer is really helpful. – Sandah Aung Jan 27 '12 at 14:12
Git-SVN import all Subversion history (and some of additional metadata) into Git repo
git svn clone url://path/to/repo -s
-s if you have "standard" repo-layout in Subversion
but some writers recommend to use
git svn init -s http://example.com/svn/my_proj
git svn fetch
Some additional useful reading:
- 7 steps to migrate a complete mirror of svn in git (with uncovered step "Clean up branches and tags")
- Ruby tool for importing existing svn projects into git (branches and tags are imported in a meaningful way)

- 94,711
- 9
- 78
- 110
-
also add `git svn fetch` to loop in a script, for cloning huge repos with numerous tags and deep histories (and the occasional disconnect) – prusswan Jan 26 '12 at 10:43
The most problems arise when there are non-standard branches or tags in SVN. This is when someone did not copy the trunk/
folder into tags/
or branches/
, but only subfolders of it. These folders appears as "ripped off" revisions without a common ancestor with trunk. But the content self is correct.

- 19,366
- 3
- 55
- 77
Subversion and Git differ a lot in terms how they represent history, keep metadata, handle system specific issues. Such differences cause most of the pitfalls:
Missing merge commits in Git:
Subversion keeps information on performed merges as svn:mergeinfo property on files and directories. On conversion to Git information on sub-tree merges and cherry-picks is lost as Git has no means to represent it.
See also After “git svn clone”, I still don't have fantastic branch-merging commit?
Externals and submodules:
Addition to @Sundae's answer: take a look at SmartGit — this tool can actually import svn:externals. It uses a file of a special format not supported by other Git clients though.
Empty directories:
Subversion treats directories as first-class citizens, Git doesn't — one has to add some placeholder file to keep a directory upon conversion. git-svn tries to handle this with external storage "unhandled log", but that works only when you keep using git-svn after the conversion.
svn:ignore and .gitignore, svn:eol-style/mime-type and .gitattributes:
git-svn does not convert Subversion properties into corresponding .gitattributes automatically. One has to run a specific command after the conversion to add attributes — anyway this information is lost upon conversion.
Arbitrary Subversion properties:
Any custom file and revision properties are lost when Subversion repository is converted to Git repository.
Have a look at SubGit. It copes well with most of the pitfalls, others are planned to be fixed in further versions.
SubGit is created to be a company-wide migration tool. One can use it as a one-shot conversion utility, but in general it is Subversion and Git continuous synchronization tool. More information you can find on its documentation page.
I was able to migrate svn history, with branch history, to git repository using the script I wrote here:
https://github.com/onepremise/SGMS
You can support both formats:
/trunk
/Project1
/Project2
/branches
/Project1
/Project2
/tags
/Project1
/Project2
This scheme is also popular and supported as well:
/Project1
/trunk
/branches
/tags
/Project2
/trunk
/branches
/tags

- 3,827
- 2
- 20
- 27