[masklinn]

> 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.