About the 50 character commit subject line limit

[thomie]

In this blog post you argue for clear git commit subject lines. I wondered how strongly you feel about the 50 character limit you mention there.

For example, in the ghc project we're up to ticket numbers in the 10000s. Following the 50 character limit leaves very little room to include the ticket number in the subject line.

You mention it's not a hard limit, and I wondered if we could still change it. I cannot find that many tools which actually suffer from subject lines between 50 and say 72 characters (gitweb being the exception). Github seems to use a 72 limit for the subject, which works great for me also.

Would a pull request to change the vim syntax highlighter to warn after 72 characters for the commit subject be accepted?

I notice you use very short subject lines yourself, which is of course great.

[dkozel]

@thomie This question on Stack Overflow has an interesting plot of commit summary length for the Linux kernel project.
http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting

Based on that I'd say starting the warning at 50 seems reasonable. It's not a hard restriction so provides the freedom to go higher as need be.

[thomie]

@dkozel why is 50 reasonable based on that?

Sure it's not a hard restriction, but a warning suggests something is wrong. Why show a warning for about half of those commits?

Note that the kernel documentation says: "the "summary" must be no more than 70-75 characters" .

Why I care:
The ghc git-hook shows me a fat giant (but soft) WARNING every time I do a git push with subject lines between 50 and 80. It's quite annoying. The justification is basically Tim's original blog post, and other tools that started (softly) enforcing it. I was hoping there's still time for change.

[cbartlett]

Why would you put the ticket number in the subject?

The ticket number is great to have. You can trace things back if you need to dig deeper and you can certainly parse the number out in an automated fashion. You can move Trello cards or post Pivotal comments or close GitHub issues. But what possible benefit is there to having that in the first line? The first line is, as @tpope says, "used all over Git" and it's used a summary and in truncated commit lists. How is the ticket number useful in those places?

I believe a soft word limit is more useful than a character limit. Your changeset should be summarized and worded imperatively, typically in 5 words or less. My average across projects is 3.1 words. Handle failed payments, Improve queue performance, Fix mobile device display, Limit subscriptions to 5, Bump Stripe version, Remove unused code, Verify phone number format are some examples.

I like this method because if your changeset cannot be summarized in just a few words, then you're probably committing too much at once. And your probably not writing something that can be grokked in an instant by a newcomer.

[dkozel]

@thomie

I feel that the warning is a useful thing to have as a reminder that I should be succinct. The room for disagreement is what length to have it at. Making it configurable is probably a good decision so projects can make that arbitrary decision on their own. A default of 50 is defensible as it is the average length of summaries for the kernel project, a very large, popular, and complex project. The indicator will appear for half of the messages, but it's just that, a warning that you're getting a bit verbose. In the GHC case maybe you set it to 56 to account for the ticket number.

Maybe it's my specific theme, but the extent of the warning that I get is that the font changes color at 50 characters while composing the commit message. What warning do you observe?