Son of the reposturgeon!
<p>Somebody said &#8220;Release early, release often.&#8221; once&#8230;and, just a day after reposurgeon 1.5, <a href="">reposurgeon</a> 1.6 is out, with a bug fix and a tasty new feature.</p>
<p><span id="more-3905"></span></p>
<p>The bug fix should prevent Python 3.2 from blowing up on the code.  More significant is that I found a way to eliminate a fiddly step in my <a href="http://www.catb.org/esr/dvcs-migration-guide.html">migration guide</a>.</p>
<p>git-svn creates a local repository that is arranged for use as a live gateway to the remote Subversion repo.  So it preserves information about the mapping between git commits and Subversion commits.  But it also keeps all the branches as remotes, not what you want for a fully-converted local git repo.</p>
<p>Because of this, there are at least two programs named svn2git floating around that are wrappers around git-svn, existing mainly to move those branches.  I give  <a href="http://www.catb.org/esr/dvcs-migration-guide.html">directions for doing this by hand</a>, but it&#8217;s an error-prone step that humans really shouldn&#8217;t do.</p>
<p>Now they don&#8217;t have to.  reposurgeon&#8217;s 1.6 gitsvnparse command &#8211; which you&#8217;d run in this situation anyway to build the map of Subversion commits &#8211; does it automatically.  This is safe, because the operation is information-preserving and idempotent.</p>
<p>In a future release I&#8217;ll probably do something about converting the local lightweight tags this produces to real tag objects.</p>
<p><a href="http://www.catb.org/esr/reposurgeon/">Fear the reposturgeon!</a></p>
