I've already resigned to the fact that any changes in the codebases I tend to work on involves spelunking through past commits, trying to git-blame my way into knowing where some suspect feature came from (and thus who to ask to explain it to me).
But few things annoy me more than when, after an hour of poking around and following code being moved across files, I finally arrive at the commit that introduced the thing I'm after, only to discover that the entire commit message is "refactored $foo", or "fix $blah". Oh, and the commit touched 20 different files, implementing 3-5 different things, and the author left the company a year ago.
So if you aren't doing it already, then for the sake of everyone (including yourself few months from now): please, write descriptive commit messages, while everything is still fresh in your memory. By descriptive, I mean at least a bullet point list of everything that was changed, and why. Even if it means repeating some of the stuff from a ticket or a discussion somewhere - because none of these things will be available or easy to find few months later.
Something like:
Add feature Foo
This commit implements feature Foo, as per ticket #12345:
option $foo controls whether or not Flux blergs or blargs;
in the latter case, $this and $that will happen.
* Configuration files have been updated with the new paramter.
* Flux Controller no longer looks at unobtanium to determine
the type of blerging to perform.
* The above implies that checking Flux for the type of blerg
is now speculative, and should not be relied on in the future.
* A new utility Asdf has been added; it provides common functionality
for blarging.
...
Etc. You get the picture. It's quite easy to write a message like this when committing - it's essentially a polished brain dump. And its usefulness will be immense the next time someone has to work in this part of the codebase.