Commit Messages

[Fred Wright]

On Sat, 15 Jul 2023, David Gilman wrote:

> I imagine this can be linted in the git local commit-msg hook. It
> won't stop a dedicated offender who can push directly to master but it
> wouldn't hurt to ship it in the macports-ports repo and promote it in
> the guidelines.

It would be fairly straightforward to catch this in a pre-commit hook, and 
those apply at the time commits are created, and hence don't care about 
whether the commits will eventually be pushed directly or submitted as 
PRs.  But hooks don't propagate across repos, so such a hook would only 
apply to users who'd explicitly installed it.

Another possibility would be a receiver-side hook on GitHub, but those 
aren't intended for this sort of purpose, so constructing such a hook 
would be more complicated.

Fred Wright

> On Sat, Jul 15, 2023 at 2:58 PM Fred Wright <fw at fwright.net> wrote:
>>
>>
>> In recent times, commit messages failing to conform to the guidelines have
>> been becoming more common - specifically, the failure to include a blank
>> line after the summary.  The guidelines even state briefly why this
>> matters, though perhaps not emphatically enough.  Recent offenders are:
>>
>>         2d9585490dc87249c189c211a228984b3a3830c7
>>         331c484f0c10d378bcbf011fa14cb7fc0e1768be
>>         f5ce144934601cc243df6e02b2d47b7956acd335
>>         b395f71013212e625fb96051bcc9a31aa0b5bd26
>>
>> The standard git tools split a commit message into a summary (a.k.a.
>> subject) and a body, with the first blank line being the division point.
>> In format strings, these are %s and %b, respectively.  Some third-party
>> git tools limit the summary to the first line, so people using such tools
>> may not even notice the error, but such tools shouldn't be the standard.
>> The output of commands like "git log --oneline" and "git branch -v"
>> becomes quite annoying with this error.
>>
>> Fred Wright
>
>
>
> -- 
> David Gilman
> :DG<
>
>