summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLinus Groh <mail@linusgroh.de>2021-05-16 00:33:47 +0100
committerLinus Groh <mail@linusgroh.de>2021-05-16 00:33:47 +0100
commit84b4b06c4b9f69dd786a80ee3c9a4562aa2b0f45 (patch)
tree1283acb2ca09776d8dad20a6e0e47143b942ae59
parent10ea84a81557d63c56a2dece01bc6b32f6ba26cf (diff)
downloadserenity-84b4b06c4b9f69dd786a80ee3c9a4562aa2b0f45.zip
Meta: Discourage commit subject lines ending with a period
-rw-r--r--CONTRIBUTING.md3
1 files changed, 2 insertions, 1 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8164d68f73..affccb4828 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -47,7 +47,7 @@ Nobody is perfect, and sometimes we mess things up. That said, here are some goo
* Make sure your commits are rebased on the master branch.
* Wrap your commit messages at 72 characters.
* The first line of the commit message is the subject line, and should have the format "Category: Brief description of what's being changed". The "category" can be a subdirectory, but also something like "POSIX compliance" or "ClassName". Whatever seems logical.
-* Write the commit message subject line in the imperative mood ("Foo: Change the way dates work", not "Foo: Changed the way dates work")
+* Write the commit message subject line in the imperative mood ("Foo: Change the way dates work", not "Foo: Changed the way dates work").
* Write your commit messages in proper English, with care and punctuation.
* Squash your commits when making revisions after a patch review.
* Add your personal copyright line to files when making substantive changes. (Optional but encouraged!)
@@ -59,6 +59,7 @@ Nobody is perfect, and sometimes we mess things up. That said, here are some goo
* Touch anything outside the stated scope of the PR.
* Iterate excessively on your design across multiple commits.
* Use weasel-words like "refactor" or "fix" to avoid explaining what's being changed.
+* End commit message subject lines with a period.
* Include commented-out code.
* Write in C. (Instead, take advantage of C++'s amenities, and don't limit yourself to the standard C library.)
* Attempt large architectural changes until you are familiar with the system and have worked on it for a while.