Git migration - github vs

Geert Janssens janssens-geert at
Sat Nov 3 08:14:44 EDT 2012

On 01-11-12 16:10, Derek Atkins wrote:
> Geert Janssens <janssens-geert at> writes:
> [snip]
>> Let's continue to build on this. I propose this setup:
>> One master repo hosted on github. One canonical repo on
>> pulls periodically from this master repo to keep in
>> sync.
>> Only selected developers have commit access to the github
>> repository. This is all access control we need here.
>> All others that wish to contribute have to fork/clone this repository
>> and send in patches.
> I would suggest that developers commit to, which can
> then push to github.
I'd rather see it the other way. If developers commit to, while all others fork from github you get a similar 
indirection like we have now with svn. I don't like that. It's a source 
for all kinds of small errors and sync irregularities. I have had to 
clean my local svn directory in git countless times because if this. 
This is no doubt partly because git and svn are two completely different 
systems, but I can envision small issues like this also in a pure git 
environment. I clearly prefer github to be the repository where all 
activity happens and a pristine canonical copy.

For non-committers, github is clearly the most interesting choice: it's 
higly visible and a well-known brand. That's where we most easily will 
come in contact with potential new contributors. I think we all agree we 
should leverage that benefit. For me then as a committer, I would really 
find it more easy if I only have to deal with one upstream repo in my 
daily activity instead of two.

I already mentioned before that I may still have my brain clinging to 
the old centralized development model of svn and may have some 
difficulty estimating correctly how simple or complicated some 
constructs are in the distributed git concept. But in my current 
understanding at least for me it's easier if I could have github as my 
main upstream for all my day to day development work and only when 
maintenance is needed on, work with that repo as upstream.


More information about the gnucash-devel mailing list