Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73572
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <1396442133.2982.286.camel@guybrush>
References: <1396441439.2982.284.camel@guybrush> <1396442133.2982.286.camel@guybrush>
Date: Thu, 3 Apr 2014 16:29:11 +0200
Message-ID: <CAMUwpuRwLLsufD_J4k5etunMRRQ43huNzoUMPuNfdoEkjVbFtQ@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Ferenc Kovacs <tyrael@php.net>, David Soria Parra <dsp@php.net>, Stanislav Malyshev <stas@php.net>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3a98d0e8667f04f6243bb6
Subject: Re: [PHP-DEV] Merging release branches back to parent
From: jpauli@php.net (Julien Pauli)

--047d7b3a98d0e8667f04f6243bb6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 2, 2014 at 2:35 PM, Johannes Schl=FCter <johannes@schlueters.de=
>wrote:

> On Wed, 2014-04-02 at 14:23 +0200, Johannes Schl=FCter wrote:
> > Hi RMs,
> >
> > we currently use release branches which we don't merge back into the
> > original branch.I would like to propose to change this and merge the
> > release branch back into it's parent branch. To the est of my
> > remembrance not doing this is a reminder of SVN merge tracking annoyanc=
e
> > which is not relevant anymore.
> >
> > The reason for this change is that it makes it hard to find out whether
> > a patch was part of a release or not and which release it appeared in
> > first.
> >
> > The suggested work flow (pushes ignored) is like this:
> >
> >      1. git checkout PHP-X.Y
> >      2. git branch PHP-X.Y.Z
> >      3. vim NEWS configure.in main/php_version.h && git commit (set to
> >         next version X.Y.Z+1)
> >      4. git checkout PHP-X.Y.Z
> >      5. test, cherry pick and release RCs as needed
> >      6. vim NEWS configure.in main/php_version.h && git commit (for
> >         release)
> >      7. git tag -s php-X.Y.Z
> >      8. git checkout PHP X.Y
> >      9. git merge PHP-X.Y.Z
> >     10. resolve merge conflict in NEWS and other files && git commit
>
> This was missing a step already done with current procedure:
>
>     11. Merge up till reaching master
>
> as we do for all other commits, obviously.
>
> johannes
>
>

Hello,


I'm not against this, but I don't feel the point.

Branching back to the original branch will just create one more commit,
adding some merging conflicts (NEWS).
What if we have cherry piked commits about CVE, will they conflict as well =
?

I'm not feeling very well yet with git, so that's why I ask.

Julien

--047d7b3a98d0e8667f04f6243bb6--