I understood the point of a statue was to be remembered if not honored for something but they forgot to describe who he was.
Eventually very little will remain to remember us by. You will likely be reduced eventually to a single commit message.
Therefore I coin a micro-format for code comments and commit messages. You should start with a child hood story, then comes a section about what you've learned that day, then you explain how it applies to the code and finally what have you done.
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.
It makes more sense that way if you think about the way in which Git is used for Linux development. They review individual commits so the commit message describes the change that will occur if that commit is pulled. Also commits can have multiple revisions as the change is improved, so past tense isn't correct because it can still change.