doc: slightly relax 50 character rule

[jasnell]

Allow commit message first line to exceed 50 chars if necessary

ping @Trott ... btw, note that the contribution guide already uses "should* and not "must"

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc

[targos]

+1: it's usually tricky to fit in 50 characters when the subsystem is child_process

[evanlucas]

would we rather do this vs switch to something like 72 columns for the title? To me, the fewer exceptions we make, the easier it is to automate around it

[addaleax]

@evanlucas I tried that back in #8327 but maybe people have changed their mind since :) I’d really like that.

[jasnell]

I'd be happy with increasing to 72 characters but perhaps lets try this first and see how it goes?

[tniessen]

No strong opinion on this, but I would prefer to relax the 50 char limit instead of making 72 the new "hard limit", mainly because this is a Git convention (as far as I know). And I am pretty sure GitHub will cut long titles at a certain length, even though I don't know whether that's less than 72 chars.

[refack]

/CC @nodejs/automation

[Fishrock123]

Can we make sure we stick within the limit of what github will take without wrapping it into the description?

[addaleax]

That’s 72, so: Yes, we’re going to do that anyway.

[Trott]

Nit: how about remove this entire bullet point and change the first bullet point to this:

• contain a short description of the change (preferably 50 characters or less)

[jasnell]

All, please take a look, fairly significant change.

[lpinca]

Still LGTM.

[Trott]

Micro-nit, non-blocking obviously: remove absolutely

[jasnell]

Landed in 1cdcab0

[Announcement]

not important, and i know this is old news; just wondering, but why 72 instead of the standard 80?

[tniessen]

@Announcement Let's see what Linus Torvalds, the inventor of Git, has to say about that:

[...] the rule is simple: we use 72-character columns for word-wrapping, except for quoted material that has a specific line format.

(And the rule is not 80 characters, because you do want to allow the standard indentation from git log, and you do want to leave some room for quoting).

Anyway, you are obviously free to do your commit messages any way you want. However, these are the rules we try to follow in the kernel, and in git itself.

And quite frankly, anybody who thinks they have better rules had better prove their point by showing a project with better commit messages. Quite frankly, I've seen a lot of open-source projects, and I have yet to see any project that does a better job of doing good commit messages than the kernel or git. And I've seen a lot of projects that do much worse.