> On 24/05/12 02:37 PM, Dan Douglas wrote: > > On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:
> > > > Of course it's read only - just like all other public > > repositories. You don't want to accept improvments? I don't > > understand this. > > I have no problem with accepting improvements, i'm just leary of > semi-official copies of the tree that could be checked out and checked > into by non-dev's (this said, I don't know that much about git but I > assume that github users could commit to the github copy yes? that > being the way users would contribute?) > >> otherwise we're going to have a rather large mess on our hands > >> (multiple forks of the main tree != a uniform main tree + > >> overlays, the way it does now) > > > > Forking happens when it's hard to contribute. You even want to > > make overlays difficult? The only real mechanism Gentoo provides > > for user extensibility? > > Nono, I was comparing the (from my perspective) mess of multiple forks > of the main tree that hosting on github/other services could > potentially enable, with a single uniform source of the main tree plus > overlays for extended contribution (which is the system we have now). Git is about decentralized version control. When you clone a repo, you have your own "fork". When everyone has their own branch, everyone is effectively equal. So yes you can expect much much more forking. In Git land, forks are good. There's no way to enforce that people only pull from some "official" source. It works out in practice so that 99% of the time people only care about a couple branches of one repository. Counterintuitively, this comes as a side- effect of git actually doing distribution properly and making it easier for everybody's workflow. The overlay model by contrast is quite broken on its own and virtually forces creation of new overlays in order to make changes without the benifits of version control (with regards to the rsync tree at least). What Github does is facilitate making it easy to fork/branch and provide a central way to push changes back into a remote through pull requests. Pull requests and other web services around git hosting are pretty much the thing that makes github worth using. From the standpoint of accepting patches, the differenc e to you is rather than (or in addition to) accepting patches through bugzilla, you can choose to accept a push directly from someone else's copy of the repo. It isn't like a wiki - everybody commits to their own repositories and pushing to a remote is on a whitelist basis just like in centralized version control. Anyway, others are better at "selling" Git than I and there are no shortage of resources out there describing distributed development models. I think this thread is supposed to be about the technical hurdles and it looks like whether or not it's feasible to support github. I can't really comment on the latter. Aside from whatever hoops the Gentoo devs have to jump through in trying to maintain multiple repos, it's hard to see the downsides to using github in and of itself. Talk to the Gentoo Haskell guys, they've been using Github for some time. And if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o -- Dan Douglas
signature.asc
Description: This is a digitally signed message part.
