On Fri, 11 Jun 2021 at 19:01, Martin Sebor wrote: > > On 6/11/21 11:32 AM, Jonathan Wakely wrote: > > On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: > >> My objection is to making our policies and tools more restrictive > >> than they need to be. We shouldn't expect everyone to study whole > >> manuals just to figure out how to successfully commit a change (or > >> learn how to format it just the right way). It should be easy. > > > > I agree, to some extent. But consistency is also good. The conventions > > for GNU ChangeLog formatting exist for a reason, and so do the > > conventions for good Git commit messages. > > > >> Setting this discussion aside for a moment and using a different > >> example, the commit hook rejects commit messages that don't start > >> ChangeLog entries with tabs. It also rejects commit messages that > >> don't list all the same test files as those changed by the commit > >> (and probably some others as well). That's in my view unnecessary > >> when the hook could just replace the leading spaces with tabs and > >> automatically mention all the tests. > >> > >> I see this proposal as heading in the same direction. Rather than > >> making the script fix things up if we get them wrong it would reject > >> the commit, requiring the user to massage the ChangeLog by hand into > >> an unnecessarily rigid format. > > > > You cannot "fix things up" in a server-side receive hook, because > > changing the commit message would alter the commit hash, which would > > require the committer to do a rebase to proceed. That breaks the > > expected behaviour and workflow of a git repo. > > > > You can use the scripts on the client side to verify your commit > > message before pushing, so you don't have to be surprised when the > > server rejects it. > > That sounds like a killer argument. Do we have shared client-side > scripts that could fix things up for us, or are we each on our own > to write them?
The scripts used in the server-side hooks are all based on what's under contrib/gcc-changelog, e.g. the contrib/gcc-changelog/git_check_com mit.py script can be used in a client-side hook to run the same checks as the server-side hook does when it receives a push. If you want to write utilities to automate things on the client-side, that's where they should go. That's also where the implementations live for the gcc-verify and gcc-commit-mklog aliases created by the contrib/gcc-git-customization.sh script.
