Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Dan Douglas <ormaaj@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]