conventionalcommits.org
conventionalcommits.org copied to clipboard
conventional-commits
Clarification on 50 char rule
There is typically a recommendation that the summary message for a commit should not exceed 50 chars. Does this still apply for conventional commits, or should the counting only include the content after the colon? This is especially relevant if the feat(...) syntax is used.
@xsrvmy including the type(scope) because most of the platform will trim commit messages around that number.
It's already difficult to fit the summary into 50 characters. With this convention, you are down to ~40 before you even start the summary. It would be great to have some recommendation in the FAQ, if not the spec, that I can point my team to.
Hey @dsbert thanks for the comment.
It is important to know that the first line needs to be ~50chars otherwise most of the code hosting platforms (GitHub, Gitlab, etc...) will trim the description, adding some ... at the end, and when reading the git history you won't be able to understand the purpose of a commit message without clicking it and then read the whole content.
Keep also in mind that you can add a very long description after the first line, meaning that the body and the footer do not have a suggested length.
In my experience the 50 chars rule is hard to follow. The limit should not be strictly enforced. For instance commit titles of the Linux kernel are in average around 50 chars and most are under the 70-75 chars (this is a soft limit proposed by developers of the Linux Kernel)
72 chars is more easy to follow than 50 chars. This is the actual limit of tools like GitHub before to add ....
I think the 50 char issue is specifically for command line tools like git log. IDK if GitHub uses character count or width with css ellipsis.
I think the 50 char issue is specifically for command line tools like git log. IDK if GitHub uses character count or width with css ellipsis.
I could even think it is related to git patch/mail workflows: the commit title is used as mail's subject and is generally prefixed with [PATCH x/y].
Also, keep in mind that the 50 char rule is not mandatory, and conventional commits do not specify it.
If you feel to add more chars to your message you are free to do that; just consider that some users won't be able to read the full commit message when navigating a UI of a website/tool.
Closing this, feel free to reopen if any of you (or others) do have other questions about it!
Even if the 50-character rule isn't part of the Conventional Commits specification, I feel like it should at least mention its existence, its reason, and why it isn't adopted. Same goes for the 72-character rule for the commit body. However, I think the specification should at least set a soft limit on the commit's description and body.
I've heard both those numbers so many times I naively thought they were universally accepted by all modern standards. I can't imagine I'm the only one.
EDIT: See #518.
