Small or large commit messages? [closed]

Question

I friend of mine and I had a discussion a few days back about the size of a commit message when using version control systems. I had the idea of committing often and small when he on the other hand used larger commit message but instead committed not so often.

I've always heard that you should, at least as a beginner, do it my way; small commit messages often. You should, if possible, summarize your commit in one sentence.

But I get the opposite feeling when looking at pro's like Linus Torvalds. Here is one commit message from him on the subsurface project on github.

This makes it consider them to be identical if they are within half a bar of each other. If you edit the pressures by hand and set them to the same bar pressure as the samples, they may not be identical to the last milli-bar, but clearly the manually entered cylinder pressure isn't significantly different from the sample data, so consider it redundant.
We do want manual overrides of cylinder pressures to take precedence over sample data (as Dirk so eloquently puts it, some dive computers really don't have very reliable sample data), but at the same time the sample data is the one we are expecting to be fairly accurate. The starting and ending pressure overrides are for when there is no sample data, or when the sample data is totally wrong for some reason.
Signed-off-by: Linus Torvalds

Here is the commit message in question.

I took a look at my own commit message (I've a few thousand of them) and they are most often always less than 40 characters.

Anyone got some input on the question?

Answer 1

You need to consider the audience for your commit messages.

If you are the only person ever to be interested in your projects, write as little as you feel like -- you just need enough to remind yourself why you chose one approach over another six months from now. You need just enough to find which specific commit changed which specific feature when you want to go bug-hunting.

If you are writing software with a team that might serve dozens or hundreds of people, the commit messages should probably be more meaningful. (This doesn't always mean longer, but it does mean "fix silly bug" is to be avoided at all costs -- "don't overrun stack buffer 'name'" is far better and almost as quick to type.)

Linus's commit messages might look huge, but he is not verbose or wordy. He's concise and gets to the point. He is writing for thousands or millions of programmers, distribution packagers, and in the specific commit message you found, divers who depend on his code for their life. They want better commit messages than might be demanded of a MMORPG checkin.