How to write a Git commit message (2014) • Hacker News Board

Re: How to write a Git commit message (2014)

#121

Post by clktmr » Wed, Apr 27, 2022, 7:00 AM UTC

ufo wrote: post #31

I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.

It's often difficult to find a summary in 50 characters, and it should be! Anything that's longer than 50 characters is probably too verbose too be viewed as a log.

Re: How to write a Git commit message (2014)

#122

Post by mhitza » Wed, Apr 27, 2022, 7:12 AM UTC

ufo wrote: post #31

I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.

I think Linus himself recommended at some point that 50 character subject restriction (in a time when 80 character wide code lines were also still a recommendation).

That wouldn't be important in itself, but Github trims your message at 50 characters as well. Because of that "feature" alone it's annoying to pass that limit.

Re: How to write a Git commit message (2014)

#123

Post by Sheen96 » Wed, Apr 27, 2022, 7:16 AM UTC

My philosophy tends to be that your first commit should convey the task you are trying to achieve and additional commits beyond that point should be fixups, to be rebased into the single first commit before merging. This removes the back and forth of changing and reverting the same files, changes from PR comments etc. It's much more coherent.

Re: How to write a Git commit message (2014)

#124

Post by wdroz » Wed, Apr 27, 2022, 7:17 AM UTC

mwt wrote: post #43

transitivebs wrote: post #18

95% of the commits on my personal open source projects use emoji commit messages. https://github.com/transitive-bullshit/commit-emoji PRs matter a lot more than commit messages, especially if you're squashing + merging / rebasing.

Honest question, do you really expect your history to be meaningful long-term? Or are you simply taking the approach that the commit message is meaningless and a developer instead use GitHub search to find a PR relevant to a change they're investigating. For example, I pulled up one of your projects and the history ( https://github.com/transitive-bullshit/kwote/commits/main ) is less than meaningless, compared to i.e…

Fastapi use gitmoji [0], this is well-documented and structured.

[0] -- https://gitmoji.dev/

Re: How to write a Git commit message (2014)

#125

Post by derkades » Wed, Apr 27, 2022, 7:32 AM UTC

mhitza wrote: post #122

ufo wrote: post #31

I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.

I think Linus himself recommended at some point that 50 character subject restriction (in a time when 80 character wide code lines were also still a recommendation). That wouldn't be important in itself, but Github trims your message at 50 characters as well. Because of that "feature" alone it's annoying to pass that limit.

GitHub trims at 72, only warns at 50

Re: How to write a Git commit message (2014)

#126

Post by rendall » Wed, Apr 27, 2022, 7:34 AM UTC

A junior dev turned me onto this several years ago, and I've gone by it ever since.

I was skeptical at first. For instance, the given reason for using imperative mode is not strong, in my opinion (the default git message on merge and revert is imperative is not a good reason, because other default git messages do not use the imperative). But, there are other good reasons for using it, not least of which is arbitrary consistency lowers cognitive load.

Now, it's my go-to if there isn't a good reason otherwise.

Re: How to write a Git commit message (2014)

#127

Post by stinos » Wed, Apr 27, 2022, 7:35 AM UTC

twhitmore wrote: post #114

Interesting topic. From my experience Headline + Bullet Points are far quicker to convey useful information, in a form that is terse yet easy to read. For example: ---------------- improve Buffer Cache Management & logging - change 'tryDrop()' to skip immediately, if lock unavailable - move BufferCache logging to a separate logger - attach BufferTrim.Unsuccessful -> Preemptive Flush of oldest buffers ----------------…

I don't really have a problem with bullet points, conveying relevant information is after all the most important thing the message should do, but if that example is an actual one then it would raise some flags during review. Mainly because it's not super readable (mix of styles, super terse requires extra interpreting) but also because it mostly explains what has changed (most often unneeded information, as that should be clear from the diff) and not really why it is done that way (ok, the code might have comments, but still I expect the message to explain that). In my experience, using bullet points like this is correlated with this style of messages which just list 'I did x, y, and z' whereas a more narrative style, which can still go in bullet points, is correlated with easily digestable messages explaining properly the reasons for changes. Anecdotal of course.

Re: How to write a Git commit message (2014)

#128

Post by rendall » Wed, Apr 27, 2022, 7:42 AM UTC

twhitmore wrote: post #114

Interesting topic. From my experience Headline + Bullet Points are far quicker to convey useful information, in a form that is terse yet easy to read. For example: ---------------- improve Buffer Cache Management & logging - change 'tryDrop()' to skip immediately, if lock unavailable - move BufferCache logging to a separate logger - attach BufferTrim.Unsuccessful -> Preemptive Flush of oldest buffers ----------------…

> Headline + Bullet Points are far quicker to convey useful information

Not sure why the quicker qualification, here. Your example follows the article's guidelines exactly. (Except, as a minor point, the initial character is upper-case).

In fact, if each of the bullets were its own commit, this would be the default message of the squash-commit to master.

Re: How to write a Git commit message (2014)

#129

Post by hoseja » Wed, Apr 27, 2022, 7:52 AM UTC

Manual wrapping for the sake of dumb terminals is such a pet-peeve of mine. Why? It's so awful to read.

Re: How to write a Git commit message (2014)

#130

Post by onion2k » Wed, Apr 27, 2022, 7:58 AM UTC

Every time I read something about "how to write good commit messages" it always seems to focus on reading the messages back as a log. That's great if that's how you use commit messages, but I tend to use them more for searching for a specific change so it doesn't really work for me. A more narrative style in commits I might need to go back to makes it easier to find them later.

How you write your commit messages should be driven by whatever you use them for afterwards.