Git Migration: where to host the master repository

[Derek Atkins]

Geert Janssens <janssens-geert at telenet.be> writes:

> 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 code.gnucash.org, you could trigger a git
> push command using github as upstream repository.
>
> But to avoid potential merging conflicts, only code.gnucash.org 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.

This is true.  Yes, I didn't think about code issuing a push against
github.  Of course that would work, too.  But as you say, the master
would necessarily have to be limited such that only code could push into
it.

> Geert

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available