Gerrit/Commit message guidelines

From MediaWiki.org
Jump to: navigation, search

The commit message plays an important role in revision control systems. They are the first thing other people will see of your commit.

Structure[edit | edit source]

Subject[edit | edit source]

The first line of the commit message is known as the subject. It describes the change briefly and helps reviewers to see at a glance what the commit is about.

  • Use the imperative mood (e.g., "Make foo do bar" instead of "[This patch] makes foo do bar" or "[I am] changing foo to do bar").
  • As being a title (not a paragraph) it should not end in a full stop.
  • Optionally prefix it with the changed component.
  • It should be no more than 50 characters (must be less than 80).

Body[edit | edit source]

Use the body of the commit message to describe your change in detail.

  • Separate the body from the subject with an empty line.
  • Give an overview of why you're committing this change.
    • What the commit changes.
    • Any new design choices made.
    • Areas to focus on for recommendations or to verify correct implementation.
    • Any research you might have done.
  • Bytes are cheap, so just write!
  • Try to make your commit message understandable without external resources (e.g., instead of just giving a URL to a mailing list archive, summarize the relevant points of the discussion).
  • Wrap the body of the message between 70 and 100 characters.
Cross-references
  • Add a "Bug: NNNNN" keyword at the end to cross-reference a Bugzilla ticket. This should trigger a "Gerrit Notification Bot" to transition the bug's status to PATCH_TO_REVIEW.
  • Gerrit's git-review tool will automatically append the "Change-Id: INNN" keyword to new commits.

Example[edit | edit source]

jquery.badge: Add ability to display the number zero

Cupcake ipsum dolor sit. Amet tart cheesecake tiramisu chocolate cake
topping. Icing ice cream sweet roll. Biscuit dragée toffee wypas. 

Does not yet address bug 44441. Follows-up Id5e7cbb1.

Bug: 12345
Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907

Of note[edit | edit source]

Patch set comments[edit | edit source]

Please do not add patch set-specific comments to the commit message body. Instead, enter patch set-specific comments as Gerrit patch set comments on the specific code lines or in the general patch set comment area.

Subject[edit | edit source]

Bear in mind that many interfaces use the subject to identify a commit, such as:

In all these cases the subject is rendered as plain text. Avoid using Bugzilla or Git references in the subject as they have no meaning in plain text. Instead mention them in the body text and/or as key-value pairs in the footer. When someone views the change in Gerrit this data is parsed (bug references, Git hashes, URLs all become linkified).

Component[edit | edit source]

You may prefix the subject with a component indicating what area of the code is affected by this commit.

It should be one of the following:

  • Group of php classes (like "uploads", "cache", "database", "resourceloader", "maintenance", "installer", etc.; typically directories in includes/).
  • Class name (like "Title", "User", "OutputPage", etc.)
  • Module name (like "mediawiki.title", "mediawiki.user", etc.)
  • Keyword affecting multiple areas relating to the type of change (e.g. "doxygen", "test", "phpcs", "qunit", or "travis")

Auto-linking and cross-referencing[edit | edit source]

Whenever you refer to another commit, use either the SHA-1 of the merged commit, or the Gerrit Change-Id of the changeset in Gerrit (avoid using Gerrit or Gitweb urls). If the commit in question has not been merged yet, use the Gerrit Change-Id instead of the SHA1 because the SHA1 changes every patch set (the SHA1 reference would potentially be a dead end).

To reference a bug (from our Bugzilla installation) in the commit message mention it inline using the bug keyword (lowercase) followed by one space and only the bug number (e.g. "That fixes bug 44441.")

To express that a commit addresses a bug, add a Bug footer[1] right above the Change-Id:

Bug: bugnumber

A bot will automatically notify Bugzilla about a new change set and any significant status changes (being merged, abandoned, etc.). Additionally, the bug's status gets set to PATCH_TO_REVIEW. This behaviour is only triggered when a change has the bug linked in the footer using the specified format. If the patch addresses two or more bugs, put each Bug: 12345 etc. reference on its own line on the bottom.

See also[edit | edit source]

References[edit | edit source]

  1. As with all headers/footers: Camel case the name, then a colon (":"), then one space. Similar to the Git commit, HTTP and E-mail headers, blank lines here would cut off the footer and wrongly include the former part in the body.