- There are two repos: "main" and "fork"
- Policies are enabled on both (but policies might be different)
- Developer pushes changes to "fork" (gets verified), then creates a PR to "main"
- PR detects all commits as non-existing (and thus as to-be-verified) because they in fact do not exist in "main", just in "fork"
- In reality, these commits are not necessarily need to be verified again when entering "main".
Problems: commits might be verified twice: in "fork" and in "main". But: if "fork" policy is less restrictive than "main" policy, the commits might be still needed to be verified.
Our current strict philosophy is to handle all commits "new" that do not yet exist in the repository that is being guarded. In the scenarios like explained above, we suggest relaxing the verification policy on "main" because the commits are already verified on "fork" some time, so they are safe to let in to "main".
Related ticket: #4566