Commit style

From OpenTTD
Revision as of 09:48, 23 October 2014 by matthijs (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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> [<FlySpray>] (r000): [<section>] 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
  • "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
<FlySpray> (optional)
If you commit a fix for a bug reported in FlySpray, add the corresponding bug number in the form of [FS#NNNN]. Do it as well if you commit a submitted patch or implement a feature with a matching FlySpray entry.
<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. Finding the trouble-causing revision is highly encouraged as it makes backporting/branching/releases that much easier.
<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 these features
  • "OSX", "Debian", "win32", for OS-specific packaging changes


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.

  • If credits were added for a commit, do not forget to remove them for the changelog as that is anonymous.


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