Should you strictly enforce the 50/72 rule?
Yesterday, I mentioned the 50/72 rule when writing Git commit messages.
The first line in the commit message is the subject line and should be no longer than 50 characters.
Any additional lines are the message body and should be wrapped at 72 characters.
As I said, I have Neovim configured to format my commit messages based on these rules, although they're more like guidelines.
There's no hard limit on the number of characters in the subject line or the number of characters in the body.
The commit will work and not be rejected when pushing to your remote repository.
There are likely post-commit Git hooks to do this, but by default, things will work.
A commit message to Drupal core today was 178 characters long, including the issue ID and contributors.
When working on project teams, ideally, everyone would follow the 50/72 rule, but if they don't consistently, I don't think it's an issue.
I'd rather they focused on writing a good and descriptive commit message and if it's formatted correctly, that's a bonus.
Whilst I could automate checks for this, I don't think it's the best use of everyone's time and, especially for Junior Developers who already have enough to learn already, not where their focus should be.
- Oliver
