I'm going to merge this into T3917, which I think is the broadest description of this issue.

Note that if the commit is actually merged, audits won't re-trigger. They only re-trigger if the commit is changed, e.g., via cherry-pick or rebase. These commits should not be categorically ignored because use cases exist for auditing them.

I'm not sure that's the same issue. Broadly, T3917 seems to describe a situation where multiple commits with the same content have different identity due to rebases or cherry-picks. This situation has to do with the exact same commit being re-audited due to merge. I guess it technically possible to review individual commits, then merge them into another branch while also making additional changes, but I would guess that's generally not the case and there doesn't seem to be a lot of use in re-auditing all the changes that have been audited individually, but now as a whole. So in a nutshell what t his is asking for is to only trigger an (automatic) audit on merge commits if:

• audit doesn't exist for all commits being merged
• there is a non-empty diff between the top of the merged branch and the top of the merge destination. I.e. there are additional changes made during the merge.

I'm having some difficulty figuring out exactly what this and related reports are describing.

If you think this isn't covered, please file a new report which meets the modern standards of either Contributing Bug Reports or Contributing Feature Requests. In particular, we need step-by-step instructions to precisely recreate an example of the "merge", since I think this term may be getting used to describe a lot of different things between this, T5338, and T3917. A real merge, a --no-ff merge, a cherry-pick, and a rebase are all distinct but I think at least some of them are being conflated.

It is also very unlikely that we will adopt any rules which categorically exclude different commits (i.e., commits A and B have different hashes) from audit based on history or content similarity or any other kind of magic rules, because this opens windows for attackers to avoid audit. If you propose a rule, you should first analyze it from the point of view of an adversarial actor: could they use the rule you propose to slip evil code into the repository without audit? If so, the rule is not likely to be acceptable to the upstream.

It seems like T3917 is asking for content similarity search (or something similar) as you mention, although falls short of automatic exclusion rules. I don't think this case is covered by T3917, but I'll file another bug, which hopefully will be more descriptive, and I'll let you be the judge of that.

Sounds good, thanks.