I'm -1. Can only assume there will be a lot of opinions here, so I'll try to at least elaborate my thoughts:

1. In terminals when using git log --graph wide lines can easily occur. Longer git titles makes this very painful to page through. Also, github will truncate (...) long titles. Not sure of the exact cutoff but I think it's around 60-70.
2. English/language argument: Valid point. On the other hand, other committers/developers should be able to help out pre-landing, similar to how code review is done.
3. The manpage of git commit suggests keeping to 50 characters or less; we'd be following suit.

I can totally relate to the problem of child_process: taking up most a fair amount of the available characters, but I think I'm -1 due to @jbergstroem's 1st and 3rd points.

Okay, given to the number of -1’s/downvotes, I’m inclined to close this a bit later. Thanks @jbergstroem for naming a few reasons for the limit!

In terminals when using git log --graph wide lines can easily occur.

True, but that’s only a concern when actively using merge commits instead of rebasing/cherry-picking, is it?

Not sure of the exact cutoff but I think it's around 60-70.

It’s 70.

The manpage of git commit suggests keeping to 50 characters or less

Interesting, I didn’t know that.

From git commit help:

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.

But that still doesn't really explain why 50 is the sweet spot.

Not sure of the exact cutoff but I think it's around 60-70.

It's 72, and it's a fair limit imho.

But that still doesn't really explain why 50 is the sweet spot.

It displays well in text-only email clients. Git started out in the linux kernel community and their workflow is built around email (and terminals.)

While it's true that the manpage suggests a limit of 50 chars it is also true that the Linux Kernel documentation does not impose such limit.

For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary. It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.

It would be great to have a soft limit of 50 chars and an hard limit of 70? chars but then I understand that it would be hard to make people respect the soft limit.

On the other hand, other committers/developers should be able to help out pre-landing, similar to how code review is done.

This can help and is a totally valid point.

Given the number of downvotes, I’m closing this. Thanks everyone for explaining where your opinions come from!

2 👍 vs. 3 👎
I demand a recount ;)

@addaleax you closed it in two days, I'm with @ronkorving

IMHO the git manual is not a strong argument as it is legacy more than lore.

@refack I’m not stopping anybody from picking this up again, but my energy for pushing contentious issues is limited and I prefer to keep it for things that matter more to me than this.