Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130963
Precedence: list
MIME-Version: 1.0
Date: Tue, 19 May 2026 15:00:52 +0300
Message-ID: <CAPyeZ4NcO_sZYe71Ef_nT0WtXfYhXpBBUFgzBgrrw_A+Oc3ZAg@mail.gmail.com>
Subject: [PHP-DEV] Merging pull requests instead of closing them
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f0c23006522a6e11"
From: udaltsov.valentin@gmail.com (Valentin Udaltsov)

--000000000000f0c23006522a6e11
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi internals,

I want to bring up something that's been bothering me since my contribution
<https://github.com/php/php-src/pull/13029>: many PRs in php-src are being
closed instead of merged, with the changes pushed separately as standalone
commits.

The problem is that GitHub marks these PRs as "Closed", not "Merged". So
from the outside =E2=80=94 and from the contributor's perspective =E2=80=94=
 it looks like
the work was rejected. Their GitHub profile shows no merged contribution,
even though the code was accepted and is now in the repo.

Beyond statistics, it also disconnects the commit from the review
discussion, and it's just confusing, especially for newer contributors who
don't know the convention.

I get that there might be reasons for this =E2=80=94 keeping a linear histo=
ry,
concerns about merge commits, etc. But rebasing or squashing before merging
solves all of that. Asking a contributor to rebase or squash is totally
normal, and most people are happy to do it.

Merging PRs is the standard across open source. It's how you signal that a
contribution was accepted.

So my question is: is there a way to make merging the default practice in
php-src? Has this been discussed before? If so, what were the blockers?

Thanks,
Valentin Udaltsov

--000000000000f0c23006522a6e11
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi internals,<br><br>I want to bring up something tha=
t&#39;s been bothering me since <a href=3D"https://github.com/php/php-src/p=
ull/13029">my contribution</a>: many PRs in php-src are being closed instea=
d of merged, with the changes pushed separately as standalone commits.<br><=
br>The problem is that GitHub marks these PRs as &quot;Closed&quot;, not &q=
uot;Merged&quot;. So from the outside =E2=80=94 and from the contributor=
9;s perspective =E2=80=94 it looks like the work was rejected. Their GitHub=
 profile shows no merged contribution, even though the code was accepted an=
d is now in the repo.<br><br>Beyond statistics, it also disconnects the com=
mit from the review discussion, and it&#39;s just confusing, especially for=
 newer contributors who don&#39;t know the convention.<br><br>I get that th=
ere might be reasons for this =E2=80=94 keeping a linear history, concerns =
about merge commits, etc. But rebasing or squashing before merging solves a=
ll of that. Asking a contributor to rebase or squash is totally normal, and=
 most people are happy to do it.<br><br>Merging PRs is the standard across =
open source. It&#39;s how you signal that a contribution was accepted.<br><=
br>So my question is: is there a way to make merging the default practice i=
n php-src? Has this been discussed before? If so, what were the blockers?<b=
r><br>Thanks,<br>Valentin Udaltsov<br></div></div>

--000000000000f0c23006522a6e11--