How I understand that: If you can't format your commit messages, how can you be considered reliable to format your code how the company defines it?
I'm sure someone can write a patch for git commit comments to enforce a 74 character limit on line width with CR\LF indiscriminately or separate them "smarter" by breaking words at 0020 after it crosses the 74 character width limit. But that's besides the point.
Patient: "It hurts when I move my arm".
Doctor: Don't move your arm.
It's absurd to take a principled stand against software alleviating development pain.
lolwut? Is anyone saying: "don't write a commit-msg hook!" or "how dare you configure a programmer's editor to wrap at a fixed width?"
I see a lot of what boils down to: "it's not my problem how you and your teams go about following a formatting standard that's popular but not mandatory."
This is a classic form of non sequitur. This kind of logic is the driver behind "If you can't be arsed to dress up in a suit and tie then you don't really care about your job" and "If you don't support our troops you are a Bad Person and you should leave the country".
Empirically, no one has shown formatting git commit messages to be predictive of code quality whatsoever. Sure, good engineers tend toward longer, more descriptive commits, but whether or not they follow proper text wrapping is totally beside the point. Poor code formatting is indicative of lack of skill, poor commit message formatting is indicative of a lack of knowledge of this one web page that most people have probably never seen.
Tell that to the plentiful amount of businesses and software development groups that enforcing good coding style is wasteful. I'll wait.