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