Git migration - github vs

Geert Janssens janssens-geert at
Sun Nov 4 17:13:29 EST 2012

On 03-11-12 15:57, John Ralls wrote:
> On Nov 3, 2012, at 5:14 AM, Geert Janssens <janssens-geert at> wrote:
>> 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.
> Why can't we set up commit hooks on each that immediately push to the other? Yes, there's a small chance of a conflict if two people push changes of the same file to each repository at the same moment, but the team is so small that that likelihood is infinitesimal.
> Otherwise, I don't see this as a big deal. Having multiple remotes in a local repo has its uses. I maintain two repos for my gtk-osx projects, one on Github and one at The latter is the "official" one, but it is indeed helpful to be able to work with contributors on Github.  Unless the change is truly trivial and obviously correct, I don't use Github's merge facility on pull requests, I pull in the patch and test it, then push it back to both repos. I also keep a personal Gnucash repo on Github. It's useful for feature branches (which I rebase from time to time, be warned!), giving me an offsite backup and anyone interested a look at what I'm up to.
> Regards,
> John Ralls

 From what I see you and Christian have the most experience with working 
in git. So I'm tempted to follow your advice. The above is mostly my 
opinion, but clearly limited due to a lack of experience.

So for now, the proposal stands as:
- github -> master repo for non-committers, highly visible, easily forked
- -> canonical repo, only used by the core developers 
(anyone with commit access to current svn)
- a sync will be set up to push each commit in code directly to github.
All other details so far as described in the previous mails in this thread.


More information about the gnucash-devel mailing list