Git Migration: where to host the master repository

Geert Janssens janssens-geert at
Tue Aug 14 11:10:40 EDT 2012

On 14-08-12 16:11, Derek Atkins wrote:
>>> I just still feel that the master repo should be on code, and that the
>>> committers should be able to push there.  Then it can sync to github for
>>> everyone else.
>>> I suppose it could work in reverse, where the committers push to github
>>> master and then code pulls from there, but I don't like that as much for
>>> reasons that I'm still apparently not able to clearly explain.
>> Since Git is distributed, the above two strategies are the same. The
>> only difference is which repo will be behind by several hours or
>> minutes depending on the pull frequency.
> True.  I could set up code to pull from github in near real-time based
> on either an email or web kick.  I don't know if there's some way to
> send github an event to kick off a pull from code.
For each commit you get on, you could trigger a git 
push command using github as upstream repository.

But to avoid potential merging conflicts, only should 
then be allowed to push to the github master repo. This is the same 
restriction as we currently have with svn -> github.

But that is irrelevant of the direction in which you wish to sync. If 
you want the sync to work without human intervention, you should avoid 
any merging conflicts. And that is easiest by guaranteeing only one 
source can push updates.


More information about the gnucash-devel mailing list