[chrisandchris]

> The former varies in length and form; the latter is concise and consistent.

IMHO, even though the latter is shorter, I did not get why it's that much better. I think in some ways, shorter is not better at all.

I try to follow these rules when writing commit messages, and had wuite good experience with them: - in the first line, name the changed subsystem/component and then a short description of what changed - follow with a list of bummet points about key changes and their reasoning, especially if something was renamed/moved/... - always reference a ticket, a comment of a ticket, or some other reference

If I re-read the commit message, I want to be able to know (or have at least an idea and to know where to look further) _why_ the code is at it is.