Clearly document the reasons for your changes in the commit log.
Detail to some degree what was changed and why. This doesn't need to be a code review/walkthrough but it should be informative to someone reading the log and looking over the diff in 6 months. The focus should be on "why" since the target audience reading the logs can usually figure out "what" from looking the diffs. As an exercise, consider the difference of usefulness between "set i to 1" and "initialize iterator correctly to fix a rarely triggering bug in memory handling".
Also, "fixed some stuff" or "cvs-1.10.0" isn't informative whereas the following example is:
"Print useful line number on error while executing .for directive."
If your change fixes a PR, document it with an appropriate message. Using the template “PR category/bug-id” in your commit message will also append it to the respective problem report in our bug database:
"Closes PR bin/6666"
If your code has been reviewed by someone else, document this:
"Reviewed by <mrg>"
(Please note that a good commit log doesn't relieve the need for good documentation in the program itself.)