[abtinf]

I’ve found the commit message guidelines at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-... to very helpful for clarity.

“ The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."”

[nirvdrum]

50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.

[hakre]

the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).

[nirvdrum]

Right. But that's the limit I don't get. If I always have to view the expanded set of commit messages to understand anything about the commit, what's the value in a short subject? And why 50 chars? That's even more restrictive than the normal 72/76/80 chars.

[GordonS]

I think a limit is helpful to keep the subject line short, but I frequently (like, daily) struggle to fit useful messages into only 50 chars. Personally, I find 72 chars to be the sweet spot.

I wish GitHub or Azure DevOps made this configurable (because I use them) - anyone know if any other hosted git systems have this as a configurable option?

[nirvdrum]

I'm in favor of a team being able to set a limit if they'd like and tools adapting. Personally, I'd rather a 90 char commit message that conveys useful info than a contorted message intended to fit in 1/3 the size of an SMS message.

[cyphar]

It's so that when you print the git-log graph, you don't end up with wrapping of the subject text for deeply-nested trees.

Also, in the kernel generally you reference a different commit in a commit message with the form 'commit <12 char commit id> ("subject")'. So further restricting it makes sense.

[nirvdrum]

Okay. But I contend that makes the whole log worth less because the short commit messages are often devoid of useful info. Granted, I don't have an email-based patch workflow; I look at logs on both GitHub and pulled in from the CLI. On GitHub, things are even worse because I have to constantly expand commits to see what actually changed.

In any event, I think teams should be free to adopt the workflow that works best for them without tools getting in the way. GitHub wrapping commit messages at 70 chars, even though I have more than plenty enough horizontal real estate, isn't helping anyone.

[hoseja]

It's still overly restrictive and ossified from terminals / email subjects or whatever.