[PATCH] Add commit message guidelines to developer policy

Renato Golin renato.golin at linaro.org
Tue Mar 10 04:36:41 PDT 2015


Hi hfinkel, rnk, chandlerc, silvas,

These are just guidelines, but we need something on the web so we can point people when they deviate too much from our expected behaviour.

These seem to be the most generic guidelines I could find from all comments on all threads.

REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8197

Files:
  docs/DeveloperPolicy.rst

Index: docs/DeveloperPolicy.rst
===================================================================
--- docs/DeveloperPolicy.rst
+++ docs/DeveloperPolicy.rst
@@ -275,6 +275,40 @@
 progress. The developer is welcome to re-commit the change after the problem has
 been fixed.
 
+Commit message
+--------------
+
+Although we don't enforce the format of commit messages, there are general
+guidelines that will help review, search in logs, email formatting and so on.
+Mostly, the rules that apply are similar to other git repositories, such as:
+
+* Separate the commit message into title, body and the optional author.
+
+* The title should be concise. All commits are emailed to the list, and the
+  first line is used as the subject, so long titles are really frowned
+  upon. They also look a lot better in a `git log`.
+
+* The body, if it exists, should be separated from the title by an empty line.
+
+* The body should be aligned to 80 columns and have as many paragraphs as
+  necessary, but not more than that. Meaning you should be concise, but
+  explanatory, including a complete reasoning, but leaving examples, code
+  snippets and gory details to bug comments, web review or the mailing list.
+
+* `Attribution of Changes`_ should be in a separate line, after the end of
+  the body, as simple as "Patch by John Doe.". This is how we officially
+  handle attribution, and there are automated processes that use that, so
+  please keep this pattern.
+
+* Text formatting and spelling should follow the same rules as documentation
+  and in-code comments, ex. capitalization, full stop, etc.
+
+While these rules match most of the cases, we're aware that some cases are not
+covered, and that's why we don't think reverting patches with "bad" commit
+messages is a reasonable thing to do. We will, however, remind people of this
+section of the policy for future reference.
+
+
 Obtaining Commit Access
 -----------------------

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D8197.21564.patch
Type: text/x-patch
Size: 1942 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150310/51674c5a/attachment.bin>


More information about the llvm-commits mailing list