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/
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 -----------------------
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
