> Curious to know what your vision of commit messages is.

Not GP, but the postgres project is a pretty good example of what I strive for:

- a title explaining what the commit does (possibly expanding into the body if details would be useful)

- plus the body explains the background for the change (the why), ideally at all levels of resolution e.g. if it’s a 1 line fix to something deep inside the bowels try to trace the path from the original high-level report or issue, then why it was fixed where it was (especially if it took ages to track down and / or decide)

- and if useful or necessary, discussions of the implementation details / options / considerations

If there’s a mailing list thread, or a bug tracker issue, it should be included, but it should not be necessary: IME it’s way more common for the log than the bug tracker to survive the sands of time, because converting history from one VCS to the next is generally relatively easy.

That reminds me of another project. Whatever you do, do not write the commit messages like that, and your are doing great: https://github.com/BeRo1985/pasvulkan/commits/master

Not everybody treats fixing software just as an excuse for writing detailed flowery diary of the development process itself consisting entirely of artisanal, handcrafted git commit messages.

Some people just fix software to fix software and for them the whole utility of git is to be able to see how the code looked earlier or even just keeping it in case they ever want to know that. They don't write commit messages because they don't read commit messages because they'd rather read code than prose. Trying to figure out what someone meant when they wrote the comment is sometimes harder than reading the code change itself. And if you need to delve deep into the prose here's the ticket number with all the words that were exchanged that lead to this change.

Someone's doing work.

My commit messages:

Fixes

Fixes

Fixes

Fix the fix

Frstegdghdsgsffff

More work

Fixes

Fixes

Commits message guidelines are a part of the contribution guidelines and are available in the documentation (linked in the GitHub page). Concrete application of said guidelines can be seen in the commit message history.