Commit message guidelines

Our commit messages for Mercurial get automatically distilled into GNU Changelog entries. The GNU coding standards have some guidelines for how to write Changelogs, and since Octave is a GNU project, we try to produce Changelogs in this style. However, certain things have to be adapted because the style in there is primarily for C sources, and because we are producing them from Mercurial commit messages.

You can see how Mercurial will produce the Changelog-style output with the following command:

 hg log --style changelog

Guidelines

General structure of a commit message:

One-line description

Empty line

Body of the commit message

Each part is explained in detail below. Here there is an example:

Give message id to undefined function error

* pt-id.cc (tree_identifier::eval_undefined_error): used
  ::error_with_id instead of ::error to report undefined functions
  with id.

One-line description

The commit message has a one-line description. Keep it short, preferrably under 80 characters. If you're squashing a bug, the bug number you're squashing should be included in this one-line description, like so at the end: (bug #12345). Omit final period (full stop).

Sometimes the one-line description is sufficient, for small changes. In that case, we use the following prefixes to give a description of what the small change is:

• maint: for reorganisation of the sources that do not change the source. Regular merge commits are a prominent example.
• doc: for changes to the documentation.

If your change only touches one file, then the filename of that file should be the prefix of the one-line description. If it's a C++ or C file, the function or class that is being modified should be included in the parenthetical remark, as in the full body of the commit message.

Body of the commit message

If there is more than one file touched in different ways and the one-line description isn't enough to describe all changes, the commit message needs a full-body description.

Individual files you touched get their changes separately enumerated. If there a particular C or C++ function you changed, the general format is

   * file.cc (class1::function1): Make change foo. 
     (class2::function2): Make change bar.

Note the newline for describing the change to a different function. General GNU style guidelines can be followed here, so that similar changes to different files can be grouped.

For style points, please also write "New function" instead of "Added function" or "Return retval" instead of "Changed to return retval".

And please, never "Fixed bug" or similar. That doesn't add any specific information about what was changed.

The changelog info in the commit message should say what changed, not why. If you need to explain why, that info should probably go in comments in the code.

For m-script and Fortran sources, the function name can be omitted if the m-script only contains one file. For changes outside of functions or classes, of course the parenthetical (function) or (class::function) specifiers can also be omitted.

Examples

• standard commit messages

allow abbreviations for optimset and optimget (bug #38999)

* optimset.m, optimget.m: Handle abbreviated keys and warn for
 ambiguous abbreviations. New tests.

add format option to ticklabel (bug #34906)

* graphics.cc: add new functions to support different input arguments to
  xyzticklabel. Add tests.
* graphics.in.h: define set_xyzticklabel as external function

tag symbols in indexed assignments as variables (bug #39240)

* pt-arg-list.cc (tree_argument_list::variable_names): Also return the
  symbol names from index expressions.
* parser.tst: New test.

• For short and very simple commit messages under 80 characters.

@ftp/cd.m: Fix docstring.

strjoin.m: delimiter can include escape sequences (matlab compatibility)

• maintenance or docs commits, no actual code changed

maint: update config.in.h in .hgignore