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)
