It looks like this is only possible with git 1.6
And you might need to install git-svn which is a separate package.
Why Git ?
Hi… i write this post so that all developers without svn write access can benefit from the power of
git. And even for developers with write access i consider git a huge step forward.
- git creates a local mirror of the WHOLE upstream repository.
- you can do local commits, and create local branches (which are very cheap in git) where you do your development in.
- no need to fear about conflicts on svn up. the svn tracking is happening in a different branch.
- its faster... and i mean a LOT faster.
A Screenshot says more than 1000 words … errr hopefully
This is “gitk --all” a very nice tool.
So what happened here ?
- I created a branch "myowncolors" to mess around with the colors.
- I changed some colors, but did not like it. But i commited. (this also translates well to adding debug output etc.)
- Then i made a change which i actually like, and want to submit for inclusion.
- I switch to the master branch which i made follow the remotes/3.0 (which is the svn-tracking branch) 3.0 has seen some commits while i was messing with the colors.
- I "cherry picked" the commit which i liked.
- In the meantime 3.0 advanced again. doh.
- now i created a branch from master named "goodColors" and "rebased" it onto trunk.
- I am ready to create a patch, and submit it.
Now all this stuff was very uncritical in terms of conflicts. But if a conflict had been there.
it would have shown up during the rebase or the cherry-pick. And these only involved the good commit.
git mergetool is there to guide you through the conflict resolution.
So i hope you get what i am actually talking about. Here is a guide so you can benefit from all this.
doing this without the repository i created at repo.or.cz
This takes a VERY long time. dont do
on the commandline you would do
git svn clone http://subversion.ardour.org/svn/ardour2 -T branches/3.0 -b branches -t tags
This would checkout EVERY revision, for EVERY branch and tag.
a significantly shorter way would be to only track the trunk.
git svn clone http://subversion.ardour.org/svn/ardour2/branches/3.0
But this would still checkout every revision in the history of 3.0.
I have already gone through the step described above using a local svn backup which speeded this process
up significantly and so it only took like 4 hours !!!
To save YOU from doing this step again, i have setup a mirror of my repository at
So you basically only need to do this:
git clone git://repo.or.cz/ardour2.git ardourgit cd ardourgit
Now you need to fetch the git-svn tracking branches which are not cloned per default.
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*' git fetch
you also need to setup the config for git-svn so that a subsequent
git svn fetch knows
where the repository is.
just paste this into
[svn-remote "svn"] rewriteRoot = http://subversion.ardour.org/svn/ardour2 url = http://subversion.ardour.org/svn branches = ardour2/branches/*:refs/remotes/* tags = ardour2/tags/*:refs/remotes/tags/* fetch = ardour2/branches/3.0:refs/remotes/3.0
Now we are almost set. The git svn metadata stored in .git/svn has not been cloned.
git-svn uses it to map from git commits to svn revisions. But it has added a git-svn-id:
to all the commit messages, which have been cloned.
So when you execute
git svn fetch now, it will rebuild its mapping from the
commit messages. And then you are set.
git svn fetch
Now you are done. You actually dont need the upstream git repo anymore,
because you can track the svn with
git svn fetch. At least remove the fetch of the svn branches again from your .git/config