Kokua:Commit Message Guidelines

Scope
The following expectations and recommendations only apply to changesets we, the Kokua contributors and Kokua project members, originally commit, not changesets we pull or cherry-pick from other projects' repositories.

When there already are applicable redmine issues, always refer to them in your commit messages
We expect all changesets that are intended to (partially) fix or implement one or several bugs/features/changes already filed on our issue tracker (redmine.kokuaviewer.org) to refer to at least one of the corresponding issue ID in its commit message.

Loosely related redmine issues
If a changeset is loosely related to one or several bugs/features/changes already filed on our issue tracker (and not fixing or implementing any other tracked issues) it is recommended to refer to at least one of the corresponding issue ID in its commit message.

Strongly related redmine issues
We recommend to refer to all redmine issues that the changeset in question fixes, implements or to which it otherwise strongly relates.

Duplicate redmine issues
There is no need to refer to issues closed as duplicates of other issues, when those other issues are being referred to already.

Reference format
Please use the format  for the aforementioned references to redmine issues, where   is the Redmine issue number on your issue tracker without the leading ' '.

Example:

Commit message layout
Please put references to features that you are implementing, bugs you are fixing or other strongly related redmine on the first line of the commit message, which serves as the 'subject line' of the commit message. Anywhere on that line is fine, but if in doubt, prefer somewhere near that line's beginning.

Additional references in the same or other formats on the first line or anywhere else in the commit message are fine where they make sense. We just want at least one reference to each referred-to issue be on the first line and of the mentioned format.

Please also include some (brief) description of the change besides the ID references required above on first line of the commit message. A longer, more detailed description is optional (though strongly encouraged for complex changesets) and should go the following lines.

Commit message content

 * First line (subject line)
 * Try to describe in prose what the specific changeset changes. If you feel unable to come up with something appropriate, let the redmine issue's 'subject' field inspire you. (Often, it works to just prepended by "fixed" or "implemented" to the content of that field as appropriate to get a useful commit message 'subject'.)


 * Other lines (optional)
 * The more detailed 'why' and 'how' of the change would go here. Use prose, enumerations or whatever you feel will help others to understand your change.