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.
