[ynik]

Looks like they did a force-push that replaced the PR's from-branch (septicmk/v6d:main) with the state of the target branch. This effectively removes all commits from the PR, leaving the PR with zero remaining commits. All of the zero commits on the PR are fully merged into v6d-io/v6d:main, thus marking the PR as merged (technically correct, but confusing).

So in effect, unauthorized merges (PR looking merged; email notifications being sent) are possible if they are "zero-commit-merges" that don't actually change any state in the git repository.

[sighingnow]

The "zero-commit-merges" should be treated as a "Closed" event better than being treated as a "Merged" event.

[tadfisher]

From Git's perspective, the two "forks" share the same HEAD commit, e.g. they are merged. That is what a merge does. A branch is a name that exists independently of the commit and points to it, so the commit history is not actually a property of the branch, despite what Git UIs tell you.

Thus, in the underlying data structure behind the GitHub interface, there really isn't an "event" here to identify. The PR branch points to the same commit as the base branch, therefore both branches are in the state of existing as "merged" with one another.

So GitHub would have to track changes to the PR branch that result in this state separately from the existing "merge from GUI" and "push PR branch to master" changes, which I could imagine is fraught with edge cases that could result in what you consider a merge event ending up as a closed event.

[wazari972]

indeed, I could reproduce it, just force push `master` into a PR, github UI will close the PR, marked it as merged, delete the source branch ... but of course nothing happens in the git repo :/