Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58748
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <slrnjle9jf.mfm.dsp@experimentalworks.net>
References: <slrnjl54vo.mfm.dsp@experimentalworks.net>
	<4F5336B2.3040200@kukulich.cz>
	<4F53DF00.6070303@gmx.net>
	<CANAnSg3COrBz2-USuJrn5pDguR4FGumPqktzsz-gkJSB5yUG+g@mail.gmail.com>
	<CAGSj+QvAeSSTXZZdVCzBgurNX-eVBu6p8on-YR4hzpDE3ubO5A@mail.gmail.com>
	<CAKOpQSzzONLbK9UALoAjx4S47zcjg=H8+R6H4sncWv_yLnPXEg@mail.gmail.com>
	<slrnjle9jf.mfm.dsp@experimentalworks.net>
Date: Wed, 7 Mar 2012 10:46:47 -0800
Message-ID: <CAKOpQSy3TuFetwj9OZ8Pha+G-PjCZbR1ouTVm+acCbbZdigjZQ@mail.gmail.com>
To: David Soria Parra <dsp@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d043c094eed471504baab9455
Subject: Re: [PHP-DEV] Re: Git Migration: Status Update
From: kris.craig@gmail.com (Kris Craig)

--f46d043c094eed471504baab9455
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 7, 2012 at 1:12 AM, David Soria Parra <dsp@php.net> wrote:

> On 2012-03-07, Kris Craig <kris.craig@gmail.com> wrote:
> > --f46d044304ec4e135704baa12342
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes <kiall@managedit.ie>
> wrote:
> >
> >> On Wed, Mar 7, 2012 at 6:03 AM, Drak <drak@zikula.org> wrote:
> >>
> > I know I keep promising to draft an RFC for this lol, so I'll make it a
> > high priority to put together an RFC for a PHP Git branching model
> sometime
> > this week[end].
>
> There is no need for that. PHP will continue to use release branches
> with optional feature branches. We are doing one step at a time and
> have people adopt the changes slowly. We are after all a large project
> and a lot of contributors cannot spend hours of reading into a VCS
> and a new branching model. So we are slowly moving towards new models.
>
> After all I see no need to do it differently. You can use whatever
> branching model you want in your personal github repository and then
> send a final pull request that can be merged. Adding complexity
> to the main repository for no reason is not needed. Keep the
> complexity in your personal repositories. That is after all
> one of the main benefits of a decentralized version control system.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
A few points....

   1. This really wouldn't be adding "complexity" to the repo.  We would
   merely be using a branching model that is more compatible with Git's
   feature set.  As I and others have said already, using a Subversion
   branching model on Git just doesn't make any sense.  We may as well just
   keep using SVN if we're not going to make use of Git's branching advantages.
   2. Using different branching structures between repo clones is not
   considered a good practice in Git.  On the contrary, it just makes the
   commit history that much more confusing to read.  If you use a standardized
   branching model, on the other hand, different features/contributions can be
   quickly and easily identified in the history (see "gitk --all").  In the
   event of a regression or other bad feature commit, reversing it is
*much*easier and cleaner if branches are clearly segregated.  It also
makes
   drafting the changelog a much less cumbersome task.
   3. I'm all for using a gradual approach so that people have time to get
   used to it.  However, that transition to a standards-compliant Git
   branching model is still something that does need to happen eventually.
   4. Git branching is not *nearly* as complicated or confusing as you guys
   are making it out to be.  You know how long it took me to train our IT guy
   at work on Git branching?  10 minutes.  He then made one mistake (forgot
   the --no-ff), which I corrected, and ever since he's been using it without
   any problems and raving about how much easier it is to keep track of our
   commit history now than when we were on Subversion.  Seriously, the
   learning curve is *very* minimal, even for those who are used to SVN
   branching.
   5. Enough people have expressed support for this idea to justify
   drafting an RFC and letting it be voted on IMHO.  However, I would like to
   address your concerns about confusion (though experience tells me that
   they're largely unfounded), so when I draft it I'll propose a gradual
   adoption scheme of some sort so that anyone who feels intimidated by
   adhering to mainstream accepted Git branching standards won't feel
   disenfranchised.
   6. There are also scripts that simplify this model (
   https://github.com/nvie/gitflow), though I've never used them myself.
   But I'll take a look and see if that might be something that could be
   recommended for anyone who doesn't want to spend the few minutes it would
   take to learn t his model.


--Kris

--f46d043c094eed471504baab9455--