On Tue, 15 Jun 2021, Martin Sebor wrote: > On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > > On Fri, 11 Jun 2021, Martin Sebor via Gcc 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 > > > > > > > > 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? > > > > > > > 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.
> > I hope I got your view wrong. If not: the "scripts fixing > > things up for us" direction is flawed (compared to the "scripts > > rejecting bad formats"), unless offered as a non-default option; > > please don't proceed. > > > > Why? For one, there'll always be bugs in the scripting. > > Mitigate those situations: while wrongly rejecting a commit is > > bad, wrongly "fixing things up" is worse, as a general rule. > > Better avoid that. (There's probably a popular "pattern name" > > for what I try to describe.) > > The word that comes to mind is Technophobia. Is it wise to trust > compilers to transform programs from their source form into > executables? What if there are bugs in either? What about the OS? > The whole computer, or the Internet? Our cars? Fortunately, there's > more to gain than to lose by trusting automation. If there weren't > human progress would be stuck sometime in the 1700's. > > But we're not talking about anything anywhere that sophisticated > here: a sed script to copy and paste a piece of text in > the description of a change from one place to another. It's been > done a few times before with more important data than ChangeLogs. Your hyperbole would be funnier if it wasn't too much over the top. Criticizing the suggested approach for suffering from a technical fallacy ("outsmarting the user") isn't technophobia. Keep it in the helper scripts, don't put it in a commit hook. brgds, H-P