Hacker News Reader

Comment by hprotagonist | Hacker News Reader

At about the same time, Chris Beams wrote this, which I have loved ever since:

https://chris.beams.io/posts/git-commit/

I note with some glee that magit colorizes my commit text and flags long lines,etc. largely in the style of this advice.

The money:

The seven rules of a great Git commit message

    Keep in mind: This has all been said before.

    Separate subject from body with a blank line

    Limit the subject line to 50 characters

    Capitalize the subject line

    Do not end the subject line with a period

    Use the imperative mood in the subject line

    Wrap the body at 72 characters

    Use the body to explain what and why vs. how*

View on HN

> Limit the subject line to 50 characters
It's nearly impossible to get certain points across in 50 characters. I keep mine under 72, and even then, I sometimes struggle to adequately describe a change in that little space, even at a high level, to the point that it would be useful for someone searching for something.
Honestly, all of this stuff matters way less than the actual content of the commit message anyway. Style is worthless if there is no substance.

> It's nearly impossible to get certain points across in 50 characters.
Usually that kind of stuff goes in the body of the commit message.

But most Git UIs only show the first line of the commit message when displaying the log, so if you're searching for something specific, you're only going to see that without clicking into a commit. I want that first line to tell me whether this commit is relevant to whatever I'm looking for, and it's extremely difficult to do that in 50 characters.

but that is almost entirely about formatting and cosmetics. I don't give a flying fart about line wrapping if the comment adequately explains the reasoning behind a change.

I shared a variation of this with our development managers (consciously changing "rules" to "tips & suggestions" so as not to ignite a tabs v. spaces holy war) and got very strong responses about how "as long as you get a ummary with some context and cosistency, and the issue # linked this is overkill".
Okay, well how do we enure that we get this without some guidance? It's very frustrating.

Do the team already have a consensus? Do they believe there’s a problem?

Interestingly, in the 3rd post in the submission, Pike specifically avoids mandating a style guide.
> I would rather not turn this into rules and style guides, just a widespread understanding that a changelist description is worth taking some time to write.

Reply on news.ycombinator.com