@@ -24,7 +24,7 @@ Here are the steps for submitting a change in the code base:
24
24
25
25
#. Create a new branch named after what your are working on::
26
26
27
- git checkout -b my-topic
27
+ git checkout -b my-topic -t origin/master
28
28
29
29
#. Edit the code and call ``make format `` to ensure your modifications comply
30
30
with the `coding style `__.
@@ -43,21 +43,60 @@ Here are the steps for submitting a change in the code base:
43
43
your changes do not break anything. You can also run ``make `` which will run
44
44
both.
45
45
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 <[email protected] >
98
+
99
+ __ https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
61
100
62
101
#. Push your topic branch in your forked repository::
63
102
0 commit comments