@@ -24,7 +24,7 @@ Here are the steps for submitting a change in the code base:
2424
2525#. Create a new branch named after what your are working on::
2626
27- git checkout -b my-topic
27+ git checkout -b my-topic -t origin/master
2828
2929#. Edit the code and call ``make format `` to ensure your modifications comply
3030 with the `coding style `__.
@@ -43,21 +43,60 @@ Here are the steps for submitting a change in the code base:
4343 your changes do not break anything. You can also run ``make `` which will run
4444 both.
4545
46- #. Create commits by following these simple guidelines:
47-
48- - Solve only one problem per commit.
49- - Use a short (less than 72 characters) title on the first line followed by
50- an blank line and a more thorough description body.
51- - Wrap the body of the commit message should be wrapped at 72 characters too
52- unless it breaks long URLs or code examples.
53- - If the commit fixes a Github issue, include the following line::
54-
55- Fixes: #NNNN
56-
57- Inspirations:
58-
59- https://chris.beams.io/posts/git-commit/
60- https://wiki.openstack.org/wiki/GitCommitMessages
46+ #. Once you are happy with your work, you can create a commit (or several
47+ commits). Follow these general rules:
48+
49+ - Address only one issue/topic per commit.
50+ - Describe your changes in imperative mood, e.g. *"make xyzzy do frotz" *
51+ instead of *"[This patch] makes xyzzy do frotz" * or *"[I] changed xyzzy to
52+ do frotz" *, as if you are giving orders to the codebase to change its
53+ behaviour.
54+ - Limit the first line (title) of the commit message to 60 characters.
55+ - Use a short prefix for the commit title for readability with ``git log
56+ --oneline ``. Do not use the `fix: ` nor `feature: ` prefixes. See recent
57+ commits for inspiration.
58+ - Only use lower case letters for the commit title except when quoting
59+ symbols or known acronyms.
60+ - Use the body of the commit message to actually explain what your patch
61+ does and why it is useful. Even if your patch is a one line fix, the
62+ description is not limited in length and may span over multiple
63+ paragraphs. Use proper English syntax, grammar and punctuation.
64+ - If you are fixing an issue, use appropriate ``Closes: <URL> `` or
65+ ``Fixes: <URL> `` trailers.
66+ - If you are fixing a regression introduced by another commit, add a
67+ ``Fixes: <COMMIT_ID> ("<TITLE>") `` trailer.
68+ - When in doubt, follow the format and layout of the recent existing
69+ commits.
70+ - The following trailers are accepted in commits. If you are using multiple
71+ trailers in a commit, it's preferred to also order them according to this
72+ list.
73+
74+ * ``Closes: <URL> ``: close the referenced issue or pull request.
75+ * ``Fixes: <SHA> ("<TITLE>") ``: reference the commit that introduced
76+ a regression.
77+ * ``Link: <URL> ``: any useful link to provide context for your commit.
78+ * ``Suggested-by ``
79+ * ``Requested-by ``
80+ * ``Reported-by ``
81+ * ``Co-authored-by ``
82+ * ``Tested-by ``
83+ * ``Reviewed-by ``
84+ * ``Acked-by ``
85+ * ``Signed-off-by ``: Compulsory!
86+
87+ There is a great reference for commit messages in the `Linux kernel
88+ documentation `__.
89+
90+ __ https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
91+
92+ IMPORTANT: you must sign-off your work using ``git commit --signoff ``. Follow
93+ the `Linux kernel developer's certificate of origin `__ for more details. All
94+ contributions are made under the MIT license. If you do not want to disclose
95+ your real name, you may sign-off using a pseudonym. Here is an example::
96+
97+ Signed-off-by: Robin Jarry <robin@jarry.cc>
98+
99+ __ https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
61100
62101#. Push your topic branch in your forked repository::
63102
0 commit comments