Hacker News Reader

Comment by mparlane | Hacker News Reader

The amount of times the word "updates" appears in the commits makes me feel much better at my difficulty of choosing succinct and unique commit messages.

View on HN

Those are summaries of summaries of branches of commits. Actual commit and merge messages all have good titles and descriptions.

full list: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... (very "slow" at the very end of the development cycle)

example merge: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

example commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

I picked some of the longer ones on the first page just for contrast with your impression, many have shorter commit messages, but they all have a commit message with some explanation.

Note that those aren't "change commits", but merge commits aggregating large swathes of other changes. And it's not even all merge commits, it's just the merges from Linus' "top lieutenants".

But I sympathize. I often spend more time on commit messages than the actual changes...

Indeed - when you go and look at the individual commits, the commit messages tend to be a lot more complex :)

My worst commit-message-to-code-changed ratio is a commit in the kernel with a 1307 char/175 word commit message, and a single character change...

Arguably you could frame that as "best".

Link for the curious?

It was a fix in PCI error handling on powerpc for a reasonably rare situation where the PCI card doesn't successfully come back up after we reset the slot or the PCI controller...

https://github.com/torvalds/linux/commit/949e9b827eb4736d96d...

Writing long commit messages (especially for internal/private projects) often gives me a slightly forlorn feeling, knowing that these words will almost certainly never be read again by another person, and possibly even I might never see them again. I persist only because when they do get read, they can be absolutely invaluable in explaining what on earth I was thinking at the time.

I persist only because when they do get read, they can be absolutely invaluable in explaining what on earth I was thinking at the time.

I wish I could upvote this more than once.

I really am thankful that you do write long commit messages. As a student starting out in OSS, I have had to track down why the particular piece of code is written like it and I go hunting down git blame and that really helps me. I also follow the practice when I can and hope that it helps future contributors or maintainers.

Reply on news.ycombinator.com