On Fri, 20 Sep 2024, Carlos O'Donell via Gcc wrote: > > (e) All existing pre-commit checks from hooks should be kept in some > > form, to maintain existing invariants on both tree and commit contents > > (some hook checks make sure that commits don't have commit messages > > that would cause other automated processes to fall over later, for > > example). > > These could all move to pre-commit CI checks that block merging.
Checks are supposed to apply to direct pushes as well as to merging through the PR system. (Direct pushes should I hope end up being rare on mainline, not necessarily rare on other branches. Some invariants of commit history should apply to all commits on all refs, e.g. that no-one accidentally copies an old GCC commit message in a way that confuses tooling searching for From-SVN: lines. On mainline, we might eventually want an *additional* check on direct pushes, e.g. that they have a Reason-for-direct-push: line that explains why the commit can't go through the PR system.) Obviously this does not assert what technology should be used to implement such checks on permitted ref updates in the repository (though hopefully as little code as possible is executed in the repository context, as much as possible in some separate isolated context). And arranging the implementation so as much code as possible can be used both when checking the final ref update, and in CI to check a PR that would result in such a ref update if accepted, is desirable (just as e.g. GCC shares code between the cron job that does ChangeLog updates, and the hook that checks if commits have properly formatted ChangeLog entries - though there are unfortunately still some cases that only result in the cron job falling over, not in the commits being rejected at push time). -- Joseph S. Myers josmy...@redhat.com