How to structure commits

• Structure one logical change into a single commit. The change can (and will, often) encompass changes to multiple files.
• The commit message is composed of multiple parts:
• The first line contains a concise summary of the changes in a single line.
• Then follows one empty line
• Then follows a longer description of the change
• Then follows an empty line
• Then follows the signed-off tags, see the example.
• Configure git to use your complete name, not your username.
• Use present tense for commit messages
• Don't commit incremental development, that is, half-baked, not working code. Please work until a change is complete, and then make one commit. Naturally, you will need to fix bugs in later commits, this is no problem.
• Sign off your changes. This is required for legal reasons, and to give correct attribution to contributions.
• When you introduce new files, please make sure they have a correct copyright header.
• Make sure there are no whitespace problems

Here's an example commit message in the expected form:

Add per-release analysis pass
    
Some interesting time series analysis methods are performed
on a per-release basis, so add a processing step that does
exactly this. For now, start with an analysis that computes
how similar adjacent release time series were, and store the
results into the DB for later visualisation (or comparison among
projects).
    
Signed-off-by: Wolfgang Mauerer <[email protected]>
Reviewed-by: Hans Huber <[email protected]>