Hello, I am the creator of the Odin programming language, and main architect of the codebase too. Being full of commits labelled "Fix <thing>" is absolutely fine and absolutely clear with all of the context of how the codebase operates.

Many of the things are "Fix #NNN` which means fixing a specific GitHub issue which usually has more information to it or has comments in the code, etc. There are many "Fix typo(s)" commits because I (and others) make a lot of typos; these are usually trivial/single-line fixes. Then it comes to the rest of "Fix ..." commits which are pretty much 1-2 line fixes of minor bugs; with large bugs having multi-line commit messages and many with huge comments within the code to explain everything.

Your metric of the quality of commit messages is not a bad one depending on the codebase, but it cannot be used blindly without knowing how that codebase operates. Especially comparing a mostly centralized codebases (like Odin) to very GNU-style decentralized codebases (all of the examples you gave).

When I'm evaluating the quality of a nuclear plant, I focus on the shape and color of the bike shed.

Naturally, commit messages aren't the only criteria I'm using. But I wasted way too much time in my life on deciphering the purpose of 20+ year old commits to ignore this.

When I want to discard the opinions of HN commenters I always go for tired, worn-out references that I don’t even understand myself.

A commit message has a function which is directly applicable to the craft of programming and not something auxiliary like the aesthetic properties of a shed used by the bicycle commuters. Though in this case I would disagree with the GP since “Fix <thing>” might be a good enough commit message template.

How many developers are there? For single developer projects, commit messages have very little value compared to documentation and an extensive passing test suite.

As the project grows in contributors, the commit log gains value

>How many developers are there?

According to GitHub, there are 132 contributors. Probably most of them were one-off drive-by PRs, but nonetheless, it's definitely not a one person project anymore.

I think Odin is (mainly) written by a single dev. When I'm the solo dev on a project, I also don't put a lot of effort into commit messages.

Even if you're a solo dev, you will likely still have to debug your old code in the future. I'm sure most of HN is familiar with the Chesterton's fence. Proper commit messages aid you in understanding why the changes were made. This especially matters in complex codebases, like compilers.

How is telling you exactly what was fixed not informative? I don't understand what you want.

What was broken? How it was broken? Why it was fixed this way? That information is vital during "git blame".

Take a look at the commit histories of the other projects I've linked. Their commit messages are much more elaborate.

>What was broken?

<thing>

That’s a decent commit message style, actually. It would be bad if it was just “Fix”. :)