Re: Merging pull requests instead of closing them

On Tue, May 19, 2026, at 14:31, Gina P. Banyard wrote: > On Tuesday, 19 May 2026 at 13:04, Valentin Udaltsov <udaltsov.valentin@gmail.com> wrote: >> Hi internals, >> >> I want to bring up something that's been bothering me since my contribution <Ûz‰¸ >> Rr :ºe«6https://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 Surely between everyone on this list ... we know people who work at GitHub? — Rob