Bart’s article “svn-branches-in-git”

The original URL of Bart Trojanowski’s article is, but that site now seems permanently gone, so this version of that post is copied from the Internet Archive at

I must say that I am no fan of SVN, but SVN and I get a long a lot better since I started
using git-svn. Long ago a good friend of mine, Dave O’Neill, taught me how to handle
multiple branches using git-svn. I had used that technique until Dave taught me how to do it better.

Recently I saw this blog post which referenced Dave’s article talking about the first method. I guess Dave never got around to updating his blog with the better way. So I am going to do that here:

A few of my clients use SVN. Some I am guilty of introducing to SVN. But for this post
I need to give you an example that you can follow along with. So let’s use
shell-fm — my favorite
client — with an SVN repo located at svn://

NOTE: You should use a modern git release. If git --version is older then 1.5.3, you need to upgrade.

Let’s start by cloning this repository using git-svn:

    $ git svn clone svn:// -T trunk -b branches -t tags

NOTE: if you have commit access you may want to modify your svn:// url appropriately.

UPDATE: --stdlayout is a short form for -T trunk -b branches -t tags, and new versions of git-svn support it.

This process will take longer then an svn checkout would… a lot longer. There
are two reasons for this. (1) you are getting all the history of the project, and
(2) SVN has a very slow protocol for this purpose.

Anyway, once it’s done (it took me about 5 minutes) you will have a directory called
shell-fm with the contents of trunk checked out in it. If not for the fact that the
.svn directory is replaced with a .git directory you would have thought that you were
using a slower SVN.

Enter into your new repository and you will see that you have a master branch that is,
by default, following trunk.

    $ git branch
    * master

This is not a git tutorial
or a git svn tutorial; but I should at least show
how to update your tree, and commit to upstream.

I would like to insert here an advanced topic of packing your repository. I don’t want to explain
it here, see the [man page], but trust me it will make your git experience much more enjoyable
if you run the following once in a while:

    $ git gc

Now, to update your working tree to the latest of the branch you are currently tracking, you would run:

    $ git svn rebase

This is similar to svn update. There are likely no updates available now, so this will
do nothing.

Next, if you want to share something with the upstream svn server you would run:

    $ vim source/main.c
    $ git commit -m"this is a test" source/main.c
    $ git svn dcommit

This is similar to svn commit.

Now, let’s look at these branches I was promising:

    $ git branch -r

Each of the above is tracking a remote branch in SVN, except for trunk which is tracking trunk.
When you run git svn fetch all branches will be updated, and new branches on the remote
will be added. git svn fetch fetches the updates with out modifying the local working files
(which git svn rebase would). git svn fetch mimics standard git fetch behaviour with an
upstream git server.

Working off remote branches is usually done on local topic branches — that is to say, not
on master — but you can use whatever you want as git-svn doesn’t care.

Let’s thus create a new branch for fixing a mythical bug on the 1.2 branch.

    $ git checkout -b fixing-bad-1.2-bug 1.2

Almost immediately, and without server interaction, we get a checkout of branch 1.2
contents. You can see where you are with:

    $ git branch
    * fixing-bad-1.2-bug

If you carefully inspect output of git log you can see that git-svn reveals
the branch name and upstream SVN commit ID on the last line of each commit:

    $ git log -1
    commit 308244b0d275db460e3b4527afd51258cece4d33
    Author: strogg <strogg@7df44517-d413-0410-91cf-82ca28b36b55>
    Date:   Thu Sep 13 19:39:51 2007 +0000

        This is a patch from Wisq to make shell-fm accept 302 redirects as well as 301.

        git-svn-id: svn:// 7df44517-d413-0410-91cf-82ca28b36b55

We are on branches/1.2 commit id 252. If you prefer it, you can even get the
svn style log output with git svn logbut why?

Working on this branch is as easy as working off trunk. You edit, commit, and git svn dcommit to upstream.

Switching between your local branches is easy…

    $ git checkout -f master
    $ hack hack hack
    $ git commit

    $ git checkout -f fixing-bad-1.2-bug
    # and we're back on 1.2 bug fixing

Note that you don’t have to push your commits back to upstream immediately, or ever for that matter, to
make use of the git repository to store your local changes. But if you do decide to you just need to
run git svn dcommit.

If you’re interesting in migrating CVS to git, have a look at the CVS to git Transition Guide.

Git – it’s just that simple

sudo port install git-core +doc +gitweb +svn +bash_completion

The above is my command-line command of the day.
I’ve been doing some research over the weekend, reading up on all the current source control systems
(for which, by the way, there is no consistent acronym. The closest I can find now is DVCS – Distributed Version Control System)
and have come to the conclusion that:

  1. The developer behind Shoes is one intensively creative fucker
  2. Git is as good as it gets

The kicker came when I found the script git-p4, which allows me to use Perforce at work in conjunction with all of git’s way-cool features!

What are these features you ask? Well, if you’ve ever heard of SVK, you will love git. Because git does what SVK does natively. And SVK is known to be like a castle on shifting sand in terms of stability. Git is rock-solid.

For the uninitiated (which would be most of you), SVK lets you check out code from a Subversion (svn) repository, and then do local-only checkins and checkouts. Then once you are happy with your changes (perhaps after 20 revisions, all tracked locally by SVK), you can “push” your changes to the main svn repo.

In the same way, git lets you “pull” changes from a central repo, do many modifcations, checking them in to git each time, and do a final “push” back to the central repo. Indeed, the concepts of “central” and “non-central” repos is not embedded into git. The central repo is only central by convention. All repos are equally “central”.