Github reset

Geert Janssens janssens-geert at
Thu Jan 31 11:12:30 EST 2013

On 31-01-13 16:58, John Ralls wrote:
> On Jan 31, 2013, at 7:39 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>> Geert Janssens <janssens-geert at> writes:
>>> I think everything is in place to switch the master git repositories
>>> to and proceed with the github reset. The repos are
>>> configured at, the trigger to push all updates to a
>>> slave repo (github) are in place.
>>> The only thing left, is to actually do it. From what I can see, this
>>> requires some coordination between John and Derek as they manage the
>>> two servers involved in the switch.
>>> Here's what has to happen IMO:
>>> - Disable the push to github on John's server
>>> - Rename the current github repositories
>>> - Create new, empty repositories on github
>>> - Set the origin parameters in the gitolite repos to point at the new
>>> github repos
>>> - manually push once (git push --all in each gitolite repo)
>>> - update our git wiki page to explain the old repos will be available
>>> for a while to help migrating
>>> - (optionally) John's server could be configured to push to the
>>> renamed, old repos for as long as we want to keep them alive
>>> Did I miss anything ? Does any step require more details ?
>>> If not, I'll leave it up to John and Derek to pick a date and time to
>>> do the work.
>> I'll note that if John changes his server origin to the renamed github
>> repos then we don't need to disable the push to John's server.  But I
>> agree that that list looks correct.
> Right.
> Should we pick a date/time and announce it via "news" (on the webpage), or was the announcement last week enough warning?
> Regards,
> John Ralls
Announcing via news on the webpage is always nicer. It avoids confusion 
for people that intend to interact with the repos right at the same time 
you are doing the switch. OTOH, the switch will probably not take long, 
so the window for this is pretty small.

An announcement after the switch has been completed is probably more 
useful to spend time on.


More information about the gnucash-devel mailing list