<div dir="ltr">There are Actions usable on GitHub which can mark PRs as failing if they do not match certain quality constraints.<div><br></div><div>I have not used any of these, but these are ones that are explicitly not using the conventional commits format:</div><div><br></div><div>- <a href="https://github.com/GsActions/commit-message-checker">https://github.com/GsActions/commit-message-checker</a>: the most flexible, regex-based</div><div>- <a href="https://github.com/mristin/opinionated-commit-message">https://github.com/mristin/opinionated-commit-message</a>: opinionated</div><div>- <a href="https://github.com/platisd/bad-commit-message-blocker">https://github.com/platisd/bad-commit-message-blocker</a>: uses Python NLP to check for imperative subjects</div><div><br></div><div>-a</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 16, 2023 at 12:13 AM Fred Wright <<a href="mailto:fw@fwright.net">fw@fwright.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
On Sat, 15 Jul 2023, David Gilman wrote:<br>
<br>
> I imagine this can be linted in the git local commit-msg hook. It<br>
> won't stop a dedicated offender who can push directly to master but it<br>
> wouldn't hurt to ship it in the macports-ports repo and promote it in<br>
> the guidelines.<br>
<br>
It would be fairly straightforward to catch this in a pre-commit hook, and <br>
those apply at the time commits are created, and hence don't care about <br>
whether the commits will eventually be pushed directly or submitted as <br>
PRs.  But hooks don't propagate across repos, so such a hook would only <br>
apply to users who'd explicitly installed it.<br>
<br>
Another possibility would be a receiver-side hook on GitHub, but those <br>
aren't intended for this sort of purpose, so constructing such a hook <br>
would be more complicated.<br>
<br>
Fred Wright<br>
<br>
> On Sat, Jul 15, 2023 at 2:58 PM Fred Wright <<a href="mailto:fw@fwright.net" target="_blank">fw@fwright.net</a>> wrote:<br>
>><br>
>><br>
>> In recent times, commit messages failing to conform to the guidelines have<br>
>> been becoming more common - specifically, the failure to include a blank<br>
>> line after the summary.  The guidelines even state briefly why this<br>
>> matters, though perhaps not emphatically enough.  Recent offenders are:<br>
>><br>
>>         2d9585490dc87249c189c211a228984b3a3830c7<br>
>>         331c484f0c10d378bcbf011fa14cb7fc0e1768be<br>
>>         f5ce144934601cc243df6e02b2d47b7956acd335<br>
>>         b395f71013212e625fb96051bcc9a31aa0b5bd26<br>
>><br>
>> The standard git tools split a commit message into a summary (a.k.a.<br>
>> subject) and a body, with the first blank line being the division point.<br>
>> In format strings, these are %s and %b, respectively.  Some third-party<br>
>> git tools limit the summary to the first line, so people using such tools<br>
>> may not even notice the error, but such tools shouldn't be the standard.<br>
>> The output of commands like "git log --oneline" and "git branch -v"<br>
>> becomes quite annoying with this error.<br>
>><br>
>> Fred Wright<br>
><br>
><br>
><br>
> -- <br>
> David Gilman<br>
> :DG<<br>
><br>
></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Austin Ziegler • <a href="mailto:halostatue@gmail.com" target="_blank">halostatue@gmail.com</a> • <a href="mailto:austin@halostatue.ca" target="_blank">austin@halostatue.ca</a><br><a href="http://www.halostatue.ca/" target="_blank">http://www.halostatue.ca/</a> • <a href="http://twitter.com/halostatue" target="_blank">http://twitter.com/halostatue</a></div>