differs substantially from the prior version, are all good things
to have.
-Make sure that you have tests for the bug you are fixing.
+Make sure that you have tests for the bug you are fixing. See
+t/README for guidance.
When adding a new feature, make sure that you have new tests to show
the feature triggers the new behaviour when it should, and to show the
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
-your code. For this reason, all patches should be submitted
-"inline". If your log message (including your name on the
+your code. For this reason, each patch should be submitted
+"inline" in a separate message.
+
+Multiple related patches should be grouped into their own e-mail
+thread to help readers find all parts of the series. To that end,
+send them as replies to either an additional "cover letter" message
+(see below), the first patch, or the respective preceding patch.
+
+If your log message (including your name on the
Signed-off-by line) is not writable in ASCII, make sure that
you send off a message in the correct encoding.
You often want to add additional explanation about the patch,
other than the commit message itself. Place such "cover letter"
-material between the three dash lines and the diffstat. Git-notes
-can also be inserted using the `--notes` option.
+material between the three-dash line and the diffstat. For
+patches requiring multiple iterations of review and discussion,
+an explanation of changes between each iteration can be kept in
+Git-notes and inserted automatically following the three-dash
+line via `git format-patch --notes`.
Do not attach the patch as a MIME attachment, compressed or not.
Do not let your e-mail client send quoted-printable. Do not let
person who certified (a), (b) or (c) and I have not modified
it.
- (d) I understand and agree that this project and the contribution
- are public and that a record of the contribution (including all
- personal information I submit with it, including my sign-off) is
- maintained indefinitely and may be redistributed consistent with
- this project or the open source license(s) involved.
+ (d) I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
then you just add a line saying
- Signed-off-by: Random J Developer <random@developer.example.org>
+ Signed-off-by: Random J Developer <random@developer.example.org>
This line can be automatically added by Git if you run the git-commit
command with the -s option.
spend their time to improve your patch. Go back to step (2).
(4) The list forms consensus that the last round of your patch is
- good. Send it to the list and cc the maintainer.
+ good. Send it to the maintainer and cc the list.
(5) A topic branch is created with the patch and is merged to 'next',
and cooked further and eventually graduates to 'master'.