There are Actions usable on GitHub which can mark PRs as failing if they do not match certain quality constraints.
I have not used any of these, but these are ones that are explicitly not using the conventional commits format: - https://github.com/GsActions/commit-message-checker: the most flexible, regex-based - https://github.com/mristin/opinionated-commit-message: opinionated - https://github.com/platisd/bad-commit-message-blocker: uses Python NLP to check for imperative subjects -a On Sun, Jul 16, 2023 at 12:13 AM Fred Wright <f...@fwright.net> wrote: > > 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< > > > > -- Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca http://www.halostatue.ca/ • http://twitter.com/halostatue
