On Tue, May 19, 2026, at 14:31, Gina P. Banyard wrote:
> 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

Surely between everyone on this list ... we know people who work at GitHub?

— Rob

Reply via email to