Commit style

From OpenTTD

Jump to: navigation, search

To achieve a coherent whole and to make changelog writing easier, here are some guidelines for commit messages. There is a check-script on the SVN server to make sure we all follow those rules.


[<branch>] -<type> [<section>] (r000): Your message here (credits)

  • <branch> (optional) First, list the branch you're committing to, if any.
  • <type>Then, prefix the message with one of the following types:
    • "Add" when you added things
    • "Backport" when you backported things
    • "Branch" when you branched the trunk
    • "Cleanup" when you did a cleanup
    • "Codechange" when you did a change to the code only, which doesn't effect gameplay in any way (so no bugfix!)
    • "Change" when you made a change (use it as little as possible, unclear entry)
    • "Doc", "Documentation" when the changes are only regarding documentation
    • "Feature" when you added a feature
    • "Fix" when you fixed something (add the bug-no if you have one, FS#NN for FlySpray, NNNNNNNN for SF)
    • "Merge" when you merged a branch to the trunk
    • "Prepare" when it's something that prepares a bigger change
    • "Regression" when it came from regression tests
    • "Release" when a release is... released
    • "Remove" when you remove a branch/file
    • "Revert" when you dare to revert something
    • "Sync" when you are syncing a branch
    • "Update" for language commits only
  • <section> (optional) Add a section if applicable Examples for sections are:
    • "Network" for network specific changes
    • "NewGRF" for NewGRF additions
    • "YAPP", "NPF", for changes in thes features
    • "OSX", "Debian", "win32", for os-specific packaging changes
  • <r000> (optional) In the case of bugfixes, if you know what revision the bug was introduced (eg regression), please mention that revision as well just after the prefix or section.. Finding the trouble-causing revision is highly encouraged as it makes backporting/branching/releases that much easier.
  • Further explanations, general bitching, etc. don't go into the first line. Use a new line for those.
  • If the patch was not made by you but you have added someone else's bugfix/feature be so kind as to mention them.
    <warning>If credits were added for a commit, do not forget to remove them for the changelog as that is anonymous</warning>.


Example of an ideal commit message; feature contributed by MekMester:

-Feature [Network]: RCon (Remote Connection).
  - A server can set: 'set rcon_pw <password>' to enable rcon
  - A client can now do: 'rcon <password> "<command>"' (MekMester)

Another example. A bug introduced in r5123 was fixed:

-Fix (r5123): server could crash under certain circumstances.

Commit into the foobar branch:

[foobar] -Change: Improve some shizzle.
Personal tools