While I've naturally gravitated toward the "capitalize and use the imperative," I've never been down with the "good commit messages are 50 characters or less" mantra. Why 50? Is there an important tool that breaks if my commit message is 55, 60 or even (gasp) 70 characters? Is there a real case to be made that "Add total vocab entries per capsule limitation" is a good commit message that becomes an utter irresponsible trash fire if one spells the entire word "vocabulary?"
Yes, short, clear commit messages are good. I'm not saying "write a paragraph"; I'm not even saying that it's bad to have an arbitrary maximum length beyond which a commit message can be considered poor form. It's just that 50 is a weirdly arbitrary choice.
I completely disregard this rule. I find it much more helpful to be able to include more context in the message (even the first line).
I have a similar policy about line-lengths in code files. Sure, lines can be too long, but I find that codebases with strict line-length policies tend to have the opposite problem: too much vertical drift which makes it hard to see the big-picture of what is going on in the file.
The 50-character limit is not a hard and fast rule for me, but one case in which it is useful is when having your editor display the most recent commit message next to every line - the sidebar only has limited width, otherwise I can't read the code in question.
The commit header becomes the email "Subject:" line. 50 characters is less than 72, and allows for the inevitable "Re: Fwd: [Re:] Re:..." mess of email threads, without losing context.
Is that the reason? So if your commits aren't getting emailed anywhere, you can ignore this rule (within reason)? I would think only a small minority of git projects have email notifications enabled.
But "For long commit messages, give a summary in up to 50 characters first" solves that as well. There are good
reasons to use longer commit messages:
* Link to issue in tracker (Projects can liver longer than the use of a single tracking software or use multiple in parallel - e.g.: public and private ones).
* Important changes in behaviour might warrant a deep link into the relevant docs, even though they are part of the commit.
* Justification why something was changed can be lengthy, especially in a loaded environment (crunch time, intra- or inter-team politics).
I am aware that various workflows exist, supported by various tools, that at least partially solve the problems I mentioned. But the larger the number of people involved or the longer the history of a project, the harder it tends to
be to agree on a complete chain of tools just for the sake of keeping commit messages short.
Of course. Noone here said that the commit header shouldn't be followed up by a more detailed description. "git log --oneline" displays only the commit header.
Maybe you're mostly referring to some more complex use of --oneline, but to me that seems like more of an argument for not editing useful information out of your subject line to fit the character limit. Of course all other things being equal, a short subject line is preferable to a long one. But if you have to make a choice, I think it's often better to treat the character limit rule as a guideline.
I'm sure I've broken this rule many times, and I'm not aware that it's ever caused a problem.
Of course. It's just a guideline. All I've done is given a justification for the guideline by presenting a common usage scenario (as intended by the authors).
Everything profits from wide terminals, except the user who has limited screen space. (And while you can in theory buy more screen space, turning your head all the time has a large cost)
Yes, short, clear commit messages are good. I'm not saying "write a paragraph"; I'm not even saying that it's bad to have an arbitrary maximum length beyond which a commit message can be considered poor form. It's just that 50 is a weirdly arbitrary choice.