| 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----- |
Archives