Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105734
MIME-Version: 1.0
References: <CAEYWF=69E9OBdYxf_-n-ih1C7P+6ZYKS9t3_gHvavRzC6PTztQ@mail.gmail.com>
In-Reply-To: <CAEYWF=69E9OBdYxf_-n-ih1C7P+6ZYKS9t3_gHvavRzC6PTztQ@mail.gmail.com>
Date: Fri, 17 May 2019 10:29:34 -0500
Message-ID: <CAESVnVqWYbOX8GsmwXHMMU5MiWJLfOU8WdZHfXaqoc_7agHp-Q@mail.gmail.com>
To: Bishop Bettini <bishop@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000658c9e0589170dc6"
Subject: Re: [PHP-DEV] Git FAQ - "How to handle changes that should not merge upward?"
From: pollita@php.net (Sara Golemon)

--000000000000658c9e0589170dc6
Content-Type: text/plain; charset="UTF-8"

On Fri, May 17, 2019 at 9:56 AM Bishop Bettini <bishop@php.net> wrote:

> Our Git FAQ[1] currently says (at the bottom):
>
> > What about commits that should not be merged upwards (say, only for 5.3)?
> Should you still merge them but make it so no changes actually take place?
> Otherwise, it will the next person merging that will have to deal with the
> conflict (or worse, the changes will be merged when they shouldn't have
> been)
>
> Please, could someone supply examples as to when this scenario occurs, and
> how to handle it?
>
>
> I routinely do this for version commits on my release branch.

See:
https://github.com/php/php-src/commit/4fa32d67bf3fbea0241f0e786dbcb5517d25e1a2
Or cmb here:
https://github.com/php/php-src/commit/2d93cce03a96ee7b0265e15e2d56acd173dec682

In both cases, we do the commit on our branch, then nullify it in the first
merge, then have null merges the rest of the way down.

-Sara

--000000000000658c9e0589170dc6--