TIL that some people are playing GitHub race games to make it seem like Linus Torvalds merged their GitHub PR.

Cute trick, but no, Linus doesn't actually ever merge anything via GitHub. Explanation here.

@stsp It's possible by design because the Git protocol has no concept of "who opened a merge request" since merge requests themselves are not part of the protocol. Anyone can fundamentally claim credit for any code *merge* on GitHub by design. What they can't do is claim credit for the code (commit authorship *is* part of the protocol).

The only fix would be for GitHub to stop auto-marking PRs as merged when merge commits are pushed, but that would make things awkward since manual merges would not allow PRs to be marked merged at all. Or I guess they could do some hack where this only works if the PR author has at least one commit authored or committed by them in the merge branch. But that's hard to explain.

@marcan So the bug is Github pretending to be in charge of things it's not in charge of, by making the assumption "if a PR exists for commit hash X and X is in the mainline, then the PR must have been merged"?

@dascandy Effectively, yes. Fundamentally the issue is that a "PR" is an arbitrary human concept that is not encoded in the Git protocol itself, so the integration GitHub does is a heuristic.

@stsp Honestly, the dumber issue is that GitHub doesn't let you mark a PR as manually merged at all. In my projects we don't use merge commits, so every time I do a manual rebase/push I have to close the PR as unmerged with a comment saying "manually merged", which is just ugly.

@marcan TIL the commit hash protects the content and not the author, timestamp, email metadata. This would be all but a neat trick (but people trust GitHub too much, so it’s actually borderline fraud)

@freddy It does protect all those things. The PR author can't take credit for the code. They can just take credit for opening the PR, since PRs are not part of the Git protocol themselves.

This person opened a PR for *someone else's code* (attributed as such), which is a thing you can do because nothing connects the PR opener in GitHub's non-Git web database to the Git author of the actual commits (which is not a bad thing, because opening a PR on behalf of someone else legitimately is something that does happen).

The only thing this person did is clone the Git branch in the original mail PR, push it to their own torvalds/linux fork on GitHub, and click the "open PR" button.

@marcan oh. I didn’t look deep enough while on mobile. You’re right. The patch is not theirs and it doesn’t show as "user contributed to…" in their profile.

Good. Less of a fraud too then. I was concerned from the "showing as a kernel comitter on their profile will get them a job interview" / "there are lies on your CV" angle.

@freddy Oh I wouldn't be surprised if they intended to use the "merged" PR as CV fraud (and it's quite likely that a recruiter not familiar with any of this would fall for it).

@marcan @freddy that would be a super weird motivation for them - they have actual contributions to the kernel they could cite!

@conor @marcan @freddy I think the person who opened the PR on github is different from the person who sent the PR on the mailing lists

Or, wait, does the person who opened the github PR also have kernel contributions? 😵‍💫

@conor @freddy Then I really don't get the motivation for that fake PR. Neat party trick, but not explaining it in a comment feels rather deceptive.

@marcan @stsp Consider leaving a "Closes: http://path/to/pr" in the commit description. This will close the PR and automatically leave a comment on it. Someone looking at commits also has a clear way to find out context/discussion.

@whynothugo @stsp That will close it but not as merged, IIRC. It also doesn't make sense if the commits aren't tied to the PR themselves. Like if someone sends me some commits via PR and I rebase/cherry pick them manually, it would be weird to edit the commit messages.

Doubly so because commits on our kernel repo are intended for mainline later and mainline submissions wouldn't appreciate spurious GitHub PR references.

@sven @conor @freddy They do, at least by name.

https://lore.kernel.org/lkml/?q=ammarfaizi2

@marcan @conor @freddy i guess it's just a party trick they wanted to try or something like that then

@sven @conor @freddy I might try it next time I send an Asahi-soc pull. Curious what happens when there are multiple layers of merge commits, and at least then I'd legitimately be the PR author anyway :p

@marcan I accidentally found that GitHub counts patches you send via email as "contributions" if you use the same email in the commit and your GH account.

It was odd to see at first because GH was not involved in the process (git format-patch; mutt -H) but it's first time I see someone fooling around like this. Like... what's the point?

@sven @marcan @freddy ye, as Hector already mentioned, they have unrelated contributions. I recognised them from sent they sent for nolibc, but also they have contributed to random parts of the kernel too.

@marcan @sven @freddy I think it /should/ mark it merged, once all the commits in the branch are also in your PR to ¿Arnd?. I suspect that if the GitHub PR contains extra commits on top that it'll drop what's common to both PRs from the GitHub PR viewer once your stuff is in Linus' tree.

@elly Yeah, GitHub just uses the Git history to count contributions and the only user identifiers there are emails, so if that matches it counts the same regardless of whether the UI was involved. Which is a good thing TBH, since Git is *designed* to be used like this and it would be silly to break such stats just because commits were pushed and pulled around outside of GH.

@romu @conor @freddy The PR was sent and the GitHub PR opened the day before, so if he was targeting April Fool's that was a gamble that Linus wouldn't merge it earlier (or later) than the next day.