Git and Subversion

I like to use Git for version control. Work uses Subversion. git-svn seems to be the answer, right?

Kinda. git svn dcommit works by applying each of your git commits in turn to Subversion. This is good and bad for SVN users — it creates one SVN revision per git commit (hooray fine-grained history, boo hundreds of change emails) — but it's really bad for my git history, which now contains duplicate commits (my original commit and the same again pushed to SVN). You need a trivial merge commit before you can push to other repos; statistics are wrong; and git log becomes useless.

The alternative is use git svn set-tree, which imposes the current state of the git repo on SVN, creating one big SVN commit. This brings SVN up to date without messing with your git history, but loses all of your commit messages.

Can we get the best of both worlds? Yes.

Use git svn dcommit to push your changes into SVN. SVN is now level with git, and has up-to-date commit messages. Now use git reset --hard to revert back to before the dcommit. This will restore the sanctity of your git log, and — of course — the contents of the repo are still the same as SVN. Now use git svn set-tree to bring all the bookkeeping up to date. Make sure you don't push anywhere before resetting, or your dcommit commits will escape into the wild.

Am I crazy, or is this the best way to approach the problem?

Posted at 2009-09-16 10:54:00 by Richard Newman • Link to Git and Subversion