Issue running git-svn-mirror script on code
janssens-geert at telenet.be
Wed Jan 30 09:44:02 EST 2013
On 28-01-13 18:44, Derek Atkins wrote:
> John Ralls <jralls at ceridwen.us> writes:
>>>> Is that what's in place now (except to a stand-in repo on
>>>> code.gnucash.org 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
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