I wanted to propose a couple of recommendations for writing good commit
messages. Ultimately, I'd like to use the commit messages to effortlessly
track changes in GUS release, which is partly motivation for this.
* Always provide a log message.
* Use the log message to address the reasons behind the change, not just the
change. For example (and sorry to pick on Debbie-- she's just the most
recent committer):
"remove statement to skip entries from tpg"
This is obvious from the code, but I have no idea *why* the tpg entries were
skipped to begin with, and now what change is allowing them to be processed.
* When fixing a bug from bugzilla, reference the bug number. For example:
"Fixed bug #27, 'unable to run LoadTaxon'"
While this message doesn't really provide many details, it points to the bug
id that should provide a wealth of information about the debugging process.
* Try to avoid "fixed typo" log messages. Sometimes, however, that's all
that happened :). Which raises another point: test and compile (perl -c)
*before* you check-in.
Any other ideas for source control log messages best practices? I'll start
a wiki where we can track these.
--Mike
|
