I can see that I used "robustly" misleadingly. My intent was to get robust automation, not a robust boolean classifier; sorry. Here's my use case. In our project, every commit to a PR means that the PR needs to be re-reviewed. During a PR's lifetime, the PR's target branch might be merged into the PR multiple times. Since re-reviewing is costly, I'm exploring the possibility of not requiring it for such merge commits produced automatically because of the assumption that nothing bad can happen there. In that use case, both false positives and false negatives are _fine_, if only annoying. If it's false positive, meaning that a PR has been truly merged, but the check couldn't figure it out, re-review will be required. Not a big deal. If it's false negative, meaning that a PR has been tampered with, but looks like it hasn't, then it's okay. Why? Because the result will be the _same_ [^*] if that PR is eventually, automatically merged into the target branch by that very Git that performed the merge check. [*]: Or very, very similar.
