[eyegor]

> the usual 50 character limit.

People do this? I guess it's fine if your commits are <100 lines of code but it seems needlessly concise, to the point of losing information.

Personally, almost all my commits follow email styling: first line tries to be concise, newline, then a list of what changes have been made along with a brief justification. Feels like a bare minimum unless you'd rather tie everything into pr's (which can't be seen from command line). This is why for people unfamiliar with git I refuse to tell them about commit -m because I feel it leads to undocumented history when you need to audit code.

disclaimer: I tend to work on long lived projects (5+ years)

Edit: bonus point that I forgot - by having a detailed commit log that reads like prose, it's easy to explain "everything you guys are working on" to the non technical folks.

[TheDong]

You're arguing against a strawman because you misunderstood the parent comment.

The character limit was only referring to the subject line. Under it you can have as many lines of additional context as you wish. That's the normal way; the subject is brief, the message is arbitrarily long.

For what it's worth, the linux kernel limits it to around 70 chars and uses a subsystem prefix, so clearly that can work on large long-lived complex projects.

Your argument against 50 characters in the entire message, including the body, is not one anyone would ever argue for, so you've constructed a complete strawman.

[Vinnl]

And some useful context: the 50-character limit is the result of the subject lines then being readable next to a commit graph that Git can display.