Git migration - github vs code.gnucash.org

[John Ralls]

On Nov 3, 2012, at 5:14 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On 01-11-12 16:10, Derek Atkins wrote:
>> Geert Janssens <janssens-geert at telenet.be> writes:
>> 
>> [snip]
>>> Let's continue to build on this. I propose this setup:
>>> 
>>> One master repo hosted on github. One canonical repo on
>>> code.gnucash.org 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 code.gnucash.org, which can
>> then push to github.
> I'd rather see it the other way. If developers commit to code.gnucash.org, 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 code.gnucash.org 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 code.gnucash.org, 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 git.gnome.org. 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