stockholm/doc/Commit_Messages_Guideline.md

# Commit Messages Guideline

Commits SHOULD have the following format:

```
<namespace?> <component>: <change>

<rationale>

(<reference-name>: <reference-id>)?
```

## `<namespace>`
Defines where the change took place. This can be omitted if the
namespace is `krebs`. Namespaces may be shortened to one to four characters (
lassulus -> lass, makefu -> make, tv -> tv, shared -> sha)

## `<component>`
Name of the component which was touched. `component` is
rather fuzzy and may mean different things, just choose what would fit best.

Here are a numbers of samples for defining the component:

* Change `gum` in `krebs/3modules/makefu/default.nix`: `gum: change ip`
* Change `prepare.sh` in `krebs/4libs/infest`: `infest: prepare stockholm ISO`
* Remove `concat` in `krebs/5pkgs`: `concat: RIP`, this commit may like some `<rationale>`
* Update `types` in `krebs/3modules`: `lib/types: add managed bool to host type`
* Change host `gum` in `makefu/1systems/gum`: `ma gum: add taskserver`
* Change `tinc` module in `krebs/3modules`: `tinc module: add option enableLegacy`

## `<rationale>`
Describe some trivia why the commit was done:
```
whatsupnix: init

Import from https://github.com/NixOS/nix/issues/443#issuecomment-296752535
```

## `<reference>`
Defines external resouces related to the commit:
```
Closes: #123533
CVE: CVE-2016-00001
URL: https://example.com/CVE-2016-00001
```

## Remarks
As a general rule of thumb you can check out: https://www.slideshare.net/TarinGamberini/commit-messages-goodpractices
Of course the pattern not always fits perfectly (for example for refactoring),
just apply some common sense and define a useful commit message,
like `refactor krebs.setuid`.