Issue running git-svn-mirror script on code

Geert Janssens janssens-geert at
Thu Jan 31 05:24:16 EST 2013

On 31-01-13 04:49, John Ralls wrote:
> On Jan 30, 2013, at 6:44 AM, Geert Janssens <janssens-geert at> wrote:
>> On 28-01-13 18:44, Derek Atkins wrote:
>>> John Ralls <jralls at> writes:
>>>>>>   Is that what's in place now (except to a stand-in repo on
>>>>>> instead of github)?
>>>>> There is no stand-in repo. The current end point is gitolite
>>>>> I never imagined a stand-in repo. In retrospect I understand now it
>>>>> can be useful to test our commit hook. We can set up a hook in
>>>>> gitolite and let it push to a temporary (local) repo, just to make
>>>>> sure the hook works. Once it works, we only have to change the origin
>>>>> config parameter in the gitolite repos to point at github instead of
>>>>> the stand-in and we're done. Is that what you had in mind as well ?
>>>> Yes, exactly.
>>> Right.  I didn't think about adding a local, stand-in repo upstream of
>>> gitolite, but you're right that that would work to test our hooks.
>>> Then, as you say, just point the url to github.
>>> I guess I just need to add a new remote ("origin"?) to the repos that
>>> point to, e.g., some local repos, and we can figure out where to put the
>>> script(s).
>>> -derek
>> For the record, I worked on the hooks with Derek yesterday and today.
>> We successfully tested the push to another dummy repo from the hooks. So everything is ready to replace the github repos and configure them as upstreams for the gitolite repos.
>> About the old github repos, I was thinking we could rename them instead of deleting them right away. That could help people to rebase their local branches to the last known state before the reset in case they forgot to do that. The renamed versions will be read-only and kept around for a limited time, say a month. The migration docs on our git wiki page would just add one more step before: change the remote in the old-repo to the renamed old read-only repo on github, because that one still has the old, obsolete hashes.
>> What do you think ?
> I like that. I'll like it even more if it turns out that Github is smart enough to recognise the name change in the fork network.
> Regards,
> John Ralls
It looks like github does the right thing indeed. I have just done the test:
- create a repo on github
- fork it on github
- rename the original repo
=> the fork now claims to be forked from the renamed repo instead of the 
original one.

Nice :)


More information about the gnucash-devel mailing list