[ShteiLoups]

Yes. As is convention, commit messages should be a one line header, then and empty line an a body (if necessary).

The whole thing should be width limited to 80 or 100 characters.

And the subject line should complete the sentence "If this commit is applied, it will...". It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.

[deividy]

"It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.", are you seriously?

[zbentley]

Seems like they are. Also seems like a solid practice that far too many people ignore.

[nonconvergent]

or you can say something equivalent yet unambiguous

A good commit message isn't about convention, and no convention makes a commit message good.

When I review a commit, I need only the information I won't get from the diff that I need to understand the context and the behavior.

My brainpower is a limited resource and extra noise in my signal is extra work.

I'm totally here for `ISSUE_123456 fixes defect` and `wip` are insufficient, but I'm not writing a code blog post in there.

[lugg]

At my work we almost encourage the blog post in there idea.

It's not a hard and fast rule and it's ok to ignore it when it makes sense. But we also don't mind if your commit message takes longer to write than the code took to change and debug.

A lot of context is assumed in commits, and almost all of it is temporal. Capturing as much of that as possible pays off down the line.

Commit in the article is a good example where the context explains much more than the change.

(On the flip side, the pay off has an expiry date so I'm not extremely fussed when people lax, but it's still good to check in basic assumptions whith your code)

[deividy]

I fix about 2~4 issues by day, 20~40 commits by day. If I do write a blog post for every commit my productivity will down by 70% at least.

[ShteiLoups]

Well that's the argument about immediate productivity and good documentation.

[wool_gather]

Can you elaborate on your surprise or objection? It may not be obvious to onlookers what you're reacting to.

[deividy]

well, I think if you start with this kind of bureaucracy, you're doing it wrong. It's not funny. Also, if your app is down, clients calling and you need to fix it fast. If I need to remember this rules to fix this, people will kill me, or I will kill myself :p

[ShteiLoups]

After a few days practicing this, it becomes second nature, and doesn't hold you up at all. Commit histories also become much quicker to parse through, especially with "log --oneline".

I notice no hindrance on my speed because I write good commit messages, and always value them when I one back to them.

[nitely]

If you follow GP's convention then yes, and it's not a bad convention.

[tom_mellior]

> And the subject line should complete the sentence "If this commit is applied, it will...".

I kind of do it like this. Others use subjects that complete the sentence "This commit...", so their subjects will start with "adds", "fixes", etc. Though that adds one or two extra characters!

[ticmasta]

Like many of the pedantic things we like to argue about, I think teams/projects should choose consistency over prescription.

[bch]

I think that’s opposing incorrect things, in this case. I think the spirit of The Law should be clear and kept alive. Whether to “[If applied, this commit will] <commit msg here>” or “[This commit]<verb> <work description>” is a tiny matter of difference when the point is clear, straightforward, complete commit msgs of logically discreet-and-coherent commits. Both the above formats would fit the bill, and I think I’d be thrilled if my biggest issue w code commits amongst my team were only these two slightly different formats.

[reilly3000]

Consistency is just prescription by precedence

[dhimes]

Is the "subject line" the same as the "header" in this schema?

[ShteiLoups]

Yeah, first line, w/e