You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Stacked PR squash merges can combine the PR author's name with the merger's email #371
When a native GitHub Stacked PR is squash-merged by someone other than the PR author, the generated commit can contain a mixed author identity:
The Git author name belongs to the PR author.
The Git author email belongs to the user who merged the stack.
The original commits are correctly associated with the PR author. The incorrect email is introduced when GitHub creates the squashed commit.
As a result, the repository page may display the PR author's name while the API, contribution graph, contributor statistics, and other author-based tooling attribute the commit to the merger.
We independently reproduced this on GitHub.com in a private repository with a four-PR native stack. The stack was merged from the web UI by a user other than the PR author using Squash and merge stack.
For all four generated commits on the default branch:
The Pull Request API correctly reported author = User A.
The Pull Request API correctly reported mergedBy = User B.
The generated Git commit author was User A display name <User B GitHub noreply email>.
The committer was GitHub <noreply@github.com>.
GitHub therefore attributed every generated commit to User B instead of the PR author. This affected every layer in the stack, so it was not isolated to one pull request.
The stack was created and maintained with gh stack 0.1.0; the actual merge was performed through the GitHub web UI. We can provide the private repository, PR, and commit URLs through a private GitHub Support channel if useful.
It's good to see it only took four weeks for someone at GitHub to acknowledge it as a bug, so thank you @skarim. But disappointing it's been given so little priority that two weeks later it's still an open issue with not even a draft PR in progress. If you work in regulated domains or environments where compliance matters this effectively makes squash merges unusable due to the misattribution.
And don't get me started on this 4+ year old 400+ upvote issue from 2022 that also pertains to the provenance of merges:
Activity
sanjuruk commentedon Aug 5, 2026
We independently reproduced this on GitHub.com in a private repository with a four-PR native stack. The stack was merged from the web UI by a user other than the PR author using Squash and merge stack.
For all four generated commits on the default branch:
author = User A.mergedBy = User B.User A display name <User B GitHub noreply email>.GitHub <noreply@github.com>.GitHub therefore attributed every generated commit to User B instead of the PR author. This affected every layer in the stack, so it was not isolated to one pull request.
The stack was created and maintained with
gh stack0.1.0; the actual merge was performed through the GitHub web UI. We can provide the private repository, PR, and commit URLs through a private GitHub Support channel if useful.GigiLoria5 commentedon Aug 7, 2026
We hit the same issue in another private repository.
A stacked PR authored by User A was squash-merged by User B, and the resulting commit used:
We’ll be happy to provide further details if they might help to identify the problem and resolve it.
dvins commentedon Aug 12, 2026
How on earth did this bug make it out of QA/test.
watson commentedon Aug 27, 2026
We got bitten by this exact issue at Datadog in this PR: DataDog/dd-trace-js#9766
dvins commentedon Sep 4, 2026
It's good to see it only took four weeks for someone at GitHub to acknowledge it as a bug, so thank you @skarim. But disappointing it's been given so little priority that two weeks later it's still an open issue with not even a draft PR in progress. If you work in regulated domains or environments where compliance matters this effectively makes squash merges unusable due to the misattribution.
And don't get me started on this 4+ year old 400+ upvote issue from 2022 that also pertains to the provenance of merges:
fix(release): correct changelog author attribution (#196)