Issue running git-svn-mirror script on code

Geert Janssens janssens-geert at
Wed Jan 30 09:44:02 EST 2013

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 ?


More information about the gnucash-devel mailing list