Issue running git-svn-mirror script on code

John Ralls jralls at
Wed Jan 23 09:37:27 EST 2013

On Jan 23, 2013, at 2:31 AM, Geert Janssens <janssens-geert at> wrote:

> On 22-01-13 14:30, Derek Atkins wrote:
>> Geert Janssens <janssens-geert at> writes:
>>> Another option would be to keep John's Jeeves set up to handle all
>>> git-svn interaction until we can drop our svn set up completely.
>>> The only change needed on John's server would be that it should push
>>> all updates to the gitolite repositories instead of the github
>>> ones. The gitolite manages repos then push to github.
>>> The last part is the only part we want to keep long term: master
>>> repositories in gitolite on, which sync to github for
>>> a wider audience.
>>> In the worst case, we have to keep the git-svn stuff around until we
>>> abandon the 2.4 development. But with some tweaking, it may even be
>>> dropped sooner.
>>> So the question is: is it worth the effort to try and replicate the
>>> git-svn bridge on ?
>> Maybe..  Here's the bigger issue, if I found issues/bugs in John's
>> svn->git conversion, what do we do?  (and yes, I found a problem in the
>> conversion)
>> Let me back up.  I worked with john on IRC yesterday and tracked down
>> one issue:  I was using the wrong URL.  Apparently I need to use the
>> same URL he does, which means I cannot use the file:/// url, but instead
>> I had to use the svn+ssh:// url.  Moreover, I had to use
>>, not, so there were two issues right
>> there.  But that wasn't sufficient.
> I realised this morning that the choice of (svn) URL is no longer important. The main concern to keep the original URL was to preserve the commit hashes.
> But due to the updates to the authors file, the svn import into git will result in new hashes starting with the first commit which has a corrected author, so preserving hashes is no longer an option.
> So if you think it would be more efficient, we can do the import from another url, like your original file:/// or using (depending on which string you would like to see appear in the commit messages).
> I saw the import was completed by now, so I'm not sure if it will gain us much still by starting over once again.
> The only reason I could really think of is that once we really drop svn, the usr has little meaning left, while is more generic and will remain. So at some point in time, the imported commits will display a non-existent url. On the other hand, even with in the url, the svn paths will eventually 404, so there always will be some inconsistency left.
> That is just a small inconsistency though, perhaps not worth redoing the migration for.


Not so fast. When you git-svn-dcommit, you'll use the svn+ssh URL, and your local commit will be hashed with the resulting svn id. The mirror git, regardless of where it's running, needs to create a commit with the same hash so that when it makes the loop back to your machine, git can recognize it as the same commit and fast-forward your repo. 

John Ralls

More information about the gnucash-devel mailing list