1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 05/24/2012 03:57 PM, Dan Douglas wrote: |
5 |
> Git is about decentralized version control. When you clone a repo, |
6 |
> you have your own "fork". When everyone has their own branch, |
7 |
> everyone is effectively equal. So yes you can expect much much |
8 |
> more forking. In Git land, forks are good. There's no way to |
9 |
> enforce that people only pull from some "official" source. |
10 |
> |
11 |
> It works out in practice so that 99% of the time people only care |
12 |
> about a couple branches of one repository. Counterintuitively, this |
13 |
> comes as a side- effect of git actually doing distribution properly |
14 |
> and making it easier for everybody's workflow. The overlay model by |
15 |
> contrast is quite broken on its own and virtually forces creation |
16 |
> of new overlays in order to make changes without the benifits of |
17 |
> version control (with regards to the rsync tree at least). |
18 |
> |
19 |
> What Github does is facilitate making it easy to fork/branch and |
20 |
> provide a central way to push changes back into a remote through |
21 |
> pull requests. Pull requests and other web services around git |
22 |
> hosting are pretty much the thing that makes github worth using. |
23 |
> From the standpoint of accepting patches, the differenc e to you is |
24 |
> rather than (or in addition to) accepting patches through bugzilla, |
25 |
> you can choose to accept a push directly from someone else's copy |
26 |
> of the repo. It isn't like a wiki - everybody commits to their own |
27 |
> repositories and pushing to a remote is on a whitelist basis just |
28 |
> like in centralized version control. |
29 |
|
30 |
This gets us into another topic altogether. |
31 |
|
32 |
I do believe git pull-requests should go through Bugzilla. A |
33 |
pull-request is the equivalent to bump requests, patch fixes, and all |
34 |
sorts of stuff that we already handle through Bugzilla. Bugzilla also |
35 |
contains our history. |
36 |
|
37 |
If they happen to be needing to be pulled from github, that's fine. |
38 |
Definitely convenient for the contributor. |
39 |
|
40 |
We'll also need to clearly document how the pull-request is to be |
41 |
generated. (I vote for requiring signed pull-requests. [1]) |
42 |
|
43 |
github should not be our central point of contact. We have b.g.o for |
44 |
that. github should be on the fringes as a tool that we can use if we |
45 |
want to. |
46 |
|
47 |
[1] |
48 |
http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html |
49 |
|
50 |
- - Aaron |
51 |
-----BEGIN PGP SIGNATURE----- |
52 |
Version: GnuPG v2.0.17 (GNU/Linux) |
53 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
54 |
|
55 |
iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d |
56 |
IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ |
57 |
=MVyV |
58 |
-----END PGP SIGNATURE----- |