Keep commit message subject under 50 characters in SourceTree

Question

While moving from Hg to Git I'm also brushing up on commit-message authoring. I find that the usual bits of advice about line length for Git are:

1. First / subject line of max 50 characters;
2. Subsequent lines max 72 characters.

I'm doing most of my current Git work with SourceTree. I realize that 1 and 2 above are just typical recommendations as opposed to rules. However, regardless of their status, I'd like to get SourceTree to help me follow both those recommendations at the same time.

To do so I've enabled the following settings:

☑ Use fixed-width font for commit messages
☑ Display a column guide in commet message at [72] characters

However, this provides only limited support for the first guideline (subject lines < 50 chars). If I change the "72" to "50" my problem would be reversed (and advice 2 above becomes harder to follow). Is there any way in SourceTree to improve this situation so that it helps me with both pieces of advice? Or am I stuck with counting characters when my gut feeling instructs me to do so?

Answer 1

As far I know, sadly, no.

It is registered in Jira system of Sourcetree as an improvement with a minor priority:

https://jira.atlassian.com/browse/SRCTREE-1068

Answer 2

The 50 character recommendation actually comes from the git man page for commit.
This man page reads:

Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

The 72 character limit however is not mentioned anywhere in git. This convention has its origin by git terminal users, as git log won't break long lines at word boundaries but just keep printing the text to screen causing it to break automatically after 80 characters or whatever width your terminal is. To get a nice formatting, the idea was to choose 72 characters, as commit messages are indented by 4 spaces and if you leave another 4 spaces at the end to get symmetric padding on screen, you have 80 - 4 * 2 = 72.

My recommendation is the following:

1. Set the limit to 50, so you can keep the first line below 50 characters.
2. Ignore the 72 character limits on consecutive lines.

Reasoning:

As the 50/72 rule is very common, a lot of tools (software, web services, etc.) assume that it is okay if they shorten commit messages to the first line break or to the first 50 characters, whatever comes first. Thus if you don't put anything reasonable into the first 50 characters of your commit message, you won't see useful commit messages in these tools. Even if you don't use any of these tools, some other people working on the same project may and this will make sure these people get nice commit messages in their tools.

As for the 72 character limit, see above, this is just for displaying commit messages in a terminal window, but all the other tools like apps and web services will correctly and nicely break long lines on word boundaries, so if you don't stick to the 72 character limit, people using any of these tools won't have any issues, thus this limit is far less critical than the 50 char limit of the first line. And for terminal users, the commit messages will still be readable, despite the somewhat ugly line breaking.

IMHO it is the task of the git developers to fix the printing of commit messages in terminal and not task of the people using git to work around that limitation as what if the terminal has only 40 characters width? Then it will still have ugly breaks using 72 characters. Who has defined that a terminal must be 80 characters wide today just because this used to be the the text console width of computers in the pre-UI area of operating systems? And breaking text on word boundaries is not that hard to do.