On 08/12/2011 06:26 PM, Lester Caine wrote:
Stas Malyshev wrote:
That is not how Drupal seems to be using git ...
http://drupal.org/node/803746#clone - See 'Creating a Working Branch'
I think they're describing local modifications for the Drupal site
there, not developing Drupal. Think about it: suppose we have Drupal
versions 7.0, 7.1, 7.2. Those will be branches. But if you want to do
something into each of them, it won't do for each developer to create a
private branch for each of them - the amount of branches will quickly
get out of control. That's when you'd need forks.
Actually they are talking about developing Drupal ... "Once you have
finished working on your fix or feature, you’ll need to bring those
changes from your topic branch back into the main fooproject branch."
Bare in mind that this is more like PEAR code than compiled C code, so
the end target is different but the process is what matters. I'm not
sure that is the right way to be doing this process, but if it's what
is documented?
One of the important features of Git (although some might ague that it's
a design flaw; I see it as a feature) is that it does not impose a
specific workflow on you. There are easily a half dozen good git-based
workflows depending on your development model, as well as at least a
dozen bad ones. :-)
The GitHub model in particular actively encourages forking and "no
canonical repository". You can know that a given series of repos are
cloned from another given repo, but that doesn't intrinsically say which
is the canonical repo. You have to just collectively agree on that.
That also encourages contribution in one of two ways:
1) Fork, clone your fork to your own computer, make changes, push, file
pull request. (Good for one person working but not for open peer review.)
2) Get commit access to the "main" repository, clone it to your
computer, make changes, merge, push. (Good for a small team that allows
lots of people to commit to the mainline.)
Drupal is still relatively new to Git, and we have a patch-based
peer-review culture. For now we're using Git essentially like CVS with
fewer bugs. :-) The primary workflow for contribution is: Clone the
official repository to your computer, branch, make changes, make a patch
out of those, post to the issue queue for review, and the maintainer
commits and pushes it to his clone. We want to eventually move to every
issue having its own public read/write repository, but we haven't built
the infrastructure for that yet.
The key point there is that in Drupal, Drupal core and any given module
have a very clear official repository with very limited commit access.
There's only 2 people with commit access to Drupal itself right now,
compared to the 1000+ of PHP. Most modules have one, perhaps two people
with commit access. Everything else happens in the issue queues via
patches. We do have "unofficial repositories" that can be used for
personal forks a la GitHub, but that's not an official
infrastructure-supported feature yet. (Eventually, we hope.)
If PHP were to go Git, it would probably want to custom build a server
much like Drupal has with its own workflow model. Probably the biggest
advantage, though, is the ability to block "large" commits to mainline
until they're approved by the release manager for a given version but
without limiting people's ability to experiment. With Git, people can
experiment with unofficial, official, quasi-official, or one-off
complete repositories before or after making them "public", either for
review or merging into mainline, and it's all really really easy.
Submodules may make sense for PHP/PECL. I'm not sure. That would
likely take the form of a series of repositories, one for each PECL
module, much the way Drupal has for its modules. Then the PHP core
repository would include a submodule reference to the PECL modules that
were considered "in core" at any given time. Moving a module into/out
of PHP itself is then just a matter of adding/removing submodule
references. (Drupal does not do that currently for its core-packaged
modules, but in theory we could.)
I do think that Git would be a smart move for PHP; any limitations that
the GitHub model imposes are just that, impositions of the GitHub
model. There's no reason that Git has to be used in that fashion if
some other model would fit PHP better.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
