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?
Martin
