Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58718
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: <CAGSj+QvAeSSTXZZdVCzBgurNX-eVBu6p8on-YR4hzpDE3ubO5A@mail.gmail.com>
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>
Date: Tue, 6 Mar 2012 22:19:11 -0800
Message-ID: <CAKOpQSzzONLbK9UALoAjx4S47zcjg=H8+R6H4sncWv_yLnPXEg@mail.gmail.com>
To: Kiall Mac Innes <kiall@managedit.ie>
Cc: Drak <drak@zikula.org>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d044304ec4e135704baa12342
Subject: Re: [PHP-DEV] Re: Git Migration: Status Update
From: kris.craig@gmail.com (Kris Craig)

--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:
>
> > [snip]
> > Forcing pushes to one's own topic branches in one's own fork can be
> > acceptable providing
> > upstream maintainers know before merging (for example squashing some work
> > after peer review), but not to the central repo without some exceptional
> > reason - it could cause chaos otherwise.
>
>
> Gerrit has an interesting take on this, you are free to do whatever you
> like on refs/heads/dev/${username}/* - including force push etc.
>
> Maybe something like this could be useful?
>
> Kiall
>

Again I would just stress that, if people followed a Git branching model
and only made direct commits to feature branches they themselves
create/maintain, this scenario shouldn't be one that's likely to come up.
 Once a feature branch is complete and it's been tested/approved/whatever
(process is important), you simply do a fresh pull of the develop (or, in
this case, version) branch, rebase the feature off of that, then merge it
into the develop branch and do a push.  Using this approach, any merge
conflicts that might arise (such as overwriting work that somebody else
recently contributed) would be caught before anything is pushed.  Instead,
said conflicts are resolved manually and then Git proceeds with the merge.
 This is similar in concept to what Kiall alluded to.

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].

--Kris

--f46d044304ec4e135704baa12342--