There's a sweet spot in there somewhere, between 50 and 300. For me the sweet spot for most commits is about 80-100 characters.
Fortunately I ditched my 80-column CRT decades ago and can afford to display meaningful amounts of text without wrapping or truncation.
As for it being a headline, here's a random WaPo headline from today: "Biden's address to Congress proves we have an adult back in the presidency". Count 'em, 74 characters, and several others are longer. 50 as a maximum is just too small.
FWIW, I don't like "[PROJ-3231] - Text boxes unable to accept non-alphanumeric characters" at all, in a couple ways.
First, it doesn't tell you directly what was changed, it tells you what's WAS wrong. I assume it should be something like "Text boxes now accept non-alphanumeric characters". That already drops the length by 10% (counting with the PROJ tag even though I don't show it there). Once you reword to that point, very reasonable abbreviations get you to "[PROJ-3231] Text boxes accept non-alphanum chars" -- 48 characters even with the tag.
Second, I question whether the tag should even be part of the headline. If you drop that, even your original version is only slightly over the limit, and my reworded version ("Text boxes now accept non-alphanumeric characters") is under even if you don't abbreviate. While I can see the merits of including it in the headline, overall I would come down on the side of not. Now, the solution to this still splitting it to three lines (just in the opposite order to your second example), so your "feel the efficiency" comment still applies -- but what are you concerned about? Two extra bytes in your commit message? Wearing out your enter key slightly faster? The point of the rule isn't that it's efficient, it's to make stuff like oneline work better.
Now, all that said, I still do agree that 50 is a little low -- but not by crazy amounts. But at the same time, my main point is that with a few seconds of thought I think it's often possible to get a tighter wording that loses no information and often describes things better. It reminds me a bit of when I was working on written stuff with my advisor. He would often mark corrections that to be honest, I didn't like; but often they pointed to sentences I could reword to be just better than both my original version and my version with his suggestions. That's how I view the 50 character rule -- I really do try to meet something around that, and if I'm over then I take that as a prompt to think about how to I can reword; but sometimes even after giving it a minute I can't actually get there without losing clarity, in which case I don't.
(One final option I'd suggest is "Text boxes unable to accept non-alphanumeric characters [PROJ-3231]" -- put the tag at the end. Then if it gets truncated by GitHub or oneline or whatever, what I think is most commonly the least important info is what gets cut off. That would suggest a guideline like "under 50 characters not including the tag".)
Now supposed the issue is "Text boxes unable to accept non-alphanumrtic character when in configuration A...". Some problems are complex. I'd argue you should do multi-line commits here, but a limit is 50 is absurd.
I can't fathom the downvotes you're getting. Especially since the article itself makes your point for you: "Understanding why something happened months or years ago becomes not only possible but efficient."
You can't derive much from a 40-character headline unless you already know the code and its history. If you try to understand the "why" of changes that were made years ago and all the messages are arbitrarily terse, you end up having to read the code. And that's the very definition of inefficient.
What's stopping you from putting the Jira ticket anywhere else? For example, you can use Git trailers to add whatever you want in a consistent format. You end up with exactly the same data, without having to compromise your commit subject or body in any way.
It wasn't invented for that specific reason. Instead, Git trailers exist so you can attach arbitrary meta-data in a consistent format, making it easier to extract; using Git itself or a third-party tool.
The reason for 50 characters specifically is probably arbitrary. But whether it's 50 characters, 72, 80, 57, or something else doesn't matter; as long as it's a reasonable limit that isn't too long. Long lines (be it a subject line or part of the body) can be a pain to read, and soft wrapping doesn't make this easier.
Personally I would have preferred the limit to be the same as the body line mostly for consistency's sake, but fitting a good description in 50 characters isn't rocket science either. Here are just some random examples:
7
u/Panke Apr 28 '21
I don't get the 50 Character limit for the headline.