Git Commit Messages - Why keep the 50 character convention?

As developers, we should all know how to write a good git checkin message. Done right, it makes delving into change histories delightful rather than a chore. 

What's that? You have never been told how to write a good checkin message? Chris Beam's article is just the thing for you! (Chris explains the rules far better than I could here without going off on a tangent)

TL;DR:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

But I want to talk about Rule #2 (with a little about Rule #6 thrown in). That 50 character first line limit.

Rule 2. Limit the subject line to 50 characters

Back in the Dark Ages, when monitors were typically 80 characters wide, this limit made some physical sense. You didn't want to wrap commit summaries because it makes them scrappy (although why not limit to 72? or 80?).

But modern monitors are much higher resolution. 140 characters wide is not unusual for a terminal window, with space to spare. Some recent commit approaches actively encourage people to break this rule by cluttering the first line with irrelevant metadata - Conventional Commits, I'm looking at you... So we can ignore this bizarre 50 character recommendation for git commit 1st lines, right? 

Wrong! It turns out there is some serious design thinking about length of lines and readability behind these rules. 

Subjectively, I know I prefer 50 character lines when I want to scan the git log from the command line. So I started to research. Here's a summary of what I found. I apologise in advance to any typographers stumbling across this article for the inevitable dumbing down of a complex subject (in my defence, "Dammit, Jim, I'm a Developer not a Typographer!" 😀). Please do chip in and contribute in the comments.

In the mid-twentieth century, Swiss graphic designer Emil Ruder explored the ideal line length for readability, coming up with 50-60 characters per line, including spaces. Other sources suggest 75 characters are acceptable. Which already kind of fits with our git commit message rules.

But why? What happens when these figures are exceeded? 

It seems that when lines are too long the reader's eyes have a hard time focussing on the text. The length makes it difficult to gauge the start and end of the line. It also makes it difficult to continue onto the next line in large blocks (eg git log)

If the lines are not long enough, the eyes travel back too often.

It turns out that our mind is energised by jumping to the next line (who'd have guessed that?!), which is great as long as it doesn't happen too often. Also that extra focus wears off over the duration of the line - too long; your brain gets bored and skips things. These effects have been confirmed on screen-based text as well as the printed page.

All of this seems to confirm the readability argument of keeping the 50 (or 72) character formatting of git commit messages.

There's more - accessibility

The Web Accessibility Initiative's guidelines states that lines of text should be 80 or fewer (European) characters. So, again, limiting the line length to 50/72 seems to support this. It is all adding up!

So, what's next?

I think delving into the typography of online readability provides a fairly compelling argument to keep the 50 character/72 character rules for git commit messages, purely for readability. It's hard enough to read technical logs like this, so let's make it as easy as possible on the eye.

But what about new conventions like Conventional Commits? Putting aside that in my own opinion it is a fundamentally flawed framework, approaches like this have to stop attempting to cram metadata into the commit message and respect the information that commit messages are supposed to convey. There are now far better ways of encoding metadata. git notes is one <ahem> notable option. But the most interesting solution would be to put metadata into the commit message as commit trailers - key-value pairs that are appended to the end of the commit message on separate lines. Check out the git commit --trailer and git interpret-trailers docs for details.

Further Reading

• “Typographie”, E. Ruder - haven't read this but Ruder's work is quoted across the web on this subject 
• "The Elements of Typographic Style Applied to the Web" - an interesting design website for anyone interested
• "Reader, Come Home",  MaryAnne Wolfe - brilliant book on reading in general - the cognitive processes etc - and how reading online is fundamentally affecting the action of reading and how we assimilate information (clue: it's not good). A great read.