Hi Gary, On 12.11.2025 12:10, Gary Gregory wrote: > If the _only_ thing this does is prevent "git --force" on only the > master branch, then it seems OK, but for completeness, what are the > cons? What about --force-with-lease? I assume this would be blocked as > well?
The `--force-with-lease` option works as a sort of check-and-set operation, so I expect it would be disabled as well. The main disadvantage I see is simply that you can’t perform a force push. :-) If someone accidentally commits a secret to the repository, they would need to: 1. Temporarily disable branch protection. 2. Perform the force push. This adds a delay in an already stressful situation, but in practice the secret is already compromised the moment it’s committed. Even days later, the commit SHA and diff might be still be visible on the mailing list or retrievable from GitHub. > There should be zero automatic merging IMO, so -1 to that. We don't > need to think of the hint of a possibility of a supply chain attack, > and who knows what else. This was mentioned a couple of times before, but it is worth repeating: “auto-merge” is a misnomer. It does not merge the PR without human intervention, it only *delays* the effects of an action taken by a committer. The feature allows you to issue a *merge command* that will be executed *after* all the required workflows have terminated successfully. This means that your command is only postponed. The merge is conditional: - If a required workflow fails, the merge will not occur. - If the PR branch is updated, the “auto-merge” is disabled, as far as I have seen. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
