Apparently, Git doesn't like commit messages that start with a pound sign, which leads us to define a new standard format for commit messages.
Taken from Commit messages in the Git Handbook:
Usually, commit messages start with the (past tense) verb
* "Added" (new feature)
* "Fixed" (bug fix)
* "Changed" (task)
* "Updated" (task, due to changes in third-party code)
1. Why past tense? Present tense would seem to be perfectly fine.
Past tense is good when you describe what the bug was. When you say what the fix is, then present tense is more appropriate.
2. Why
feature request => Add
task => Change
?
As module maintainer I change feature requests into tasks when I accept them. But they're still new features, so "Add" would be more appropriate.
From the same page:
Best practice:
1. Apply a patch.
2. Add a changelog entry to CHANGELOG.txt.
Note: All lines in CHANGELOG.txt should wrap at 80 chars. If a changelog entry does not fit into 80 chars, subsequent lines belonging to the same entry should be indented by 2 spaces.
3. Copy the changelog entry and re-use it 1:1 for the Git commit message (but remove linefeeds and indents of long lines).
4. Commit.
3. Why wrap at 80 chars? I'd generally prefer one (long) line per issue...
If you want to establish arbitrary rules, you should at least give a good reason for them. Knowing the reasons makes it easier to adhere to them and to motivate others to do the same.
Comments
Changelog
Note: Not discussing the opening comment about git here; duplicates http://drupal.org/node/1059966
A changelog is a historical log of changes. People that read it always read about things that have changed in the past.
That makes no sense. Of course, you're free to do whatever you want, but in the overall Drupal development process, features are features, and tasks are tasks.
Admittedly, the definition of a task is not easy, but roughly speaking: Everything that's neither a new feature nor fixing a bug. Most often, tasks are architectural, logical, or visual optimizations — stuff that everyone may live without, but it may still be a good idea to do it.
The line actually is very thin and many people have troubles to correctly classify something as task. Many tasks on drupal.org are misclassified feature requests. And some bug reports are misclassified tasks (and vice-versa).
Consistency. All code comments/documentation in Drupal wraps at 80 chars. There is only one exception to that rule.
Daniel F. Kudwien
netzstrategen