On Tuesday, 19 May 2026 at 13:04, Valentin Udaltsov <[email protected]> wrote:
> 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 — and from the contributor's perspective — 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 — keeping a linear history, > 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? Merging PRs that target master is common practice. However, when merging bug fixes our process is to merge into the lowest branch and then up, something GitHub cannot do nor support, as sometimes we need to make changes to the fix in the merge up process. There has been discussion about this previously off list, but changing the merge process is difficult and no-one has come to an agreement. However, 90% of you complain are issues with GitHub. We amend the commit message to close the PR so that the link is preserved, and GitHub, if it would be smarter, would be able to understand that it actually means "merged" not "closed". I think relying on GitHub to provide useful statistics is just a fools errand as it doesn't even consistently mark certain things as "reviews" or not if you want to gather usage statistics. Best regards, Gina P. Banyard
