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 <f...@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<
