Git SVN Rebranching Issue

[Matt Kern <matt.kern@undue.org>]

I have a git-svn issue which keeps biting me.

My company uses svn as its primary version control system.  We
frequently create branches, e.g. /branches/somebranch, by forking the
trunk to ensure stability over the "somebranch" code.  The problem is
that we also frequently blow away /branches/somebranch and refork it
from the trunk.

git-svn does a good job for most work, but I notice that if you delete
the "somebranch" branch in svn and then refork it, also in svn, then
when you git-svn fetch, the git commit at the head of remotes/somebranch
will have two parents: the first is the previous head of
remotes/somebranch, and the second is the head of remotes/trunk.  Surely
only the remotes/trunk parent should be listed?  Any connection with the
previous remotes/somebranch is an accident of naming.  The real problem
then comes when you come to look at the history in gitk.  If
"somebranch" is rebranched many times, the git history starts looking
pretty complicated, when in fact it should simply be the linear history
of remotes/trunk up to the branch point followed by a few,
branch-specific commits.  Is there any way to prevent (or modify) the
git history to remove the errant parent?

In the ideal world, we wouldn't reuse branch names in svn, but it is
convenient and doesn't cause problems for svn users.  I can't force the
rest of the company to change to accommodate my use of git...

I am using git (svn) version 1.5.6.5 (svn 1.4.6) from Debian/Lenny and
can provide a trivial repository demonstrating the problem if anyone is
interested.

Matt

-- 
Matt Kern
http://www.undue.org/