mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-14 12:49:34 +02:00
Code Issues Packages Projects Releases Wiki Activity

dev-manual: Updated "How to submit a change" section.

Browse Source 
Fixes [YOCTO #11630]

The section on how to submit a change was pretty much a procedure
section.  I did some rewriting to make it more that way.

(From yocto-docs rev: d7edce9268ee5cae96c09c79fe34d5d2dbb701e0)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2017-06-19 16:40:13 -07:00
committed by Richard Purdie
parent 652d8cb583
commit e928b5251c
1 changed files with 303 additions and 281 deletions
Download Patch File Download Diff File Expand all files Collapse all files

584
documentation/dev-manual/dev-manual-newbie.xml
View File

@@ -444,189 +444,180 @@
<para> <para>
Contributions to the Yocto Project and OpenEmbedded are very welcome. Contributions to the Yocto Project and OpenEmbedded are very welcome.
Because the system is extremely configurable and flexible, we recognize that developers Because the system is extremely configurable and flexible, we recognize
will want to extend, configure or optimize it for their specific uses. that developers will want to extend, configure or optimize it for
You should send patches to the appropriate mailing list so that they their specific uses.
can be reviewed and merged by the appropriate maintainer.
</para> </para>
<section id='submit-change-overview'> <para>
<title>Overview</title> The Yocto Project uses a mailing list and a patch-based workflow
that is similar to the Linux kernel but contains important
differences.
In general, a mailing list exists through which you can submit
patches.
You should send patches to the appropriate mailing list so that they
can be reviewed and merged by the appropriate maintainer.
The specific mailing list you need to use depends on the
location of the code you are changing.
Each component (e.g. layer) should have a
<filename>README</filename> file that indicates where to send
the changes and which process to follow.
</para>
<para> <para>
The Yocto Project uses a mailing list and patch-based workflow You can send the patch to the mailing list using whichever approach
that is similar to the Linux kernel but contains important you feel comfortable with to generate the patch.
differences. Once sent, the patch is usually reviewed by the community at large.
In general, a mailing list exists through which you can submit If somebody has concerns with the patch, they will usually voice
patches. their concern over the mailing list.
The specific mailing list you need to use depends on the If a patch does not receive any negative reviews, the maintainer of
location of the code you are changing. the affected layer typically takes the patch, tests it, and then
Each component (e.g. layer) should have a based on successful testing, merges the patch.
<filename>README</filename> file that indicates where to send </para>
the changes and which process to follow.
</para>
<para> <para id='figuring-out-the-mailing-list-to-use'>
You can send the patch to the mailing list using whichever approach The "poky" repository, which is the Yocto Project's reference build
you feel comfortable with to generate the patch. environment, is a hybrid repository that contains several
Once sent, the patch is usually reviewed by the community at large. individual pieces (e.g. BitBake, OpenEmbedded-Core, meta-yocto,
If somebody has concerns with the patch, they will usually voice documentation, and so forth) built using the combo-layer tool.
their concern over the mailing list. The upstream location used for submitting changes varies by
If a patch does not receive any negative reviews, the maintainer of component:
the affected layer typically takes the patch, tests it, and then <itemizedlist>
based on successful testing, merges the patch. <listitem><para>
</para> <emphasis>Core Metadata:</emphasis>
Send your patch to the
<ulink url='http://lists.openembedded.org/mailman/listinfo/openembedded-core'>openembedded-core</ulink>
mailing list. For example, a change to anything under
the <filename>meta</filename> or
<filename>scripts</filename> directories should be sent
to this mailing list.
</para></listitem>
<listitem><para>
<emphasis>BitBake:</emphasis>
For changes to BitBake (i.e. anything under the
<filename>bitbake</filename> directory), send your patch
to the
<ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'>bitbake-devel</ulink>
mailing list.
</para></listitem>
<listitem><para>
<emphasis>"meta-yocto-bsp" and "meta-poky" trees:</emphasis>
These trees are
part of the "meta-yocto" repository in the Yocto Project
source repositories.
Use the
<ulink url='https://lists.yoctoproject.org/listinfo/poky'>poky</ulink>
mailing list.
</para></listitem>
</itemizedlist>
</para>
<para> <para>
Specific to OpenEmbedded-Core, two commonly used testing trees For changes to other layers hosted in the Yocto Project source
exist: repositories (i.e. <filename>yoctoproject.org</filename>), tools,
<itemizedlist> and the Yocto Project documentation, use the
<listitem><para> <ulink url='https://lists.yoctoproject.org/listinfo/yocto'>Yocto Project</ulink>
<emphasis>"ross/mut" branch:</emphasis> general mailing list.
The "mut" (master-under-test) tree <note>
exists in the <filename>poky-contrib</filename> repository Sometimes a layer's documentation specifies to use a
in the particular mailing list.
<ulink url='&YOCTO_GIT_URL;'>Yocto Project source repositories</ulink>. If so, use that list.
</para></listitem> </note>
<listitem><para> For additional recipes that do not fit into the core Metadata, you
<emphasis>"master-next" branch:</emphasis> should determine which layer the recipe should go into and submit
This branch is part of the main the change in the manner recommended by the documentation (e.g.
"poky" repository in the Yocto Project source repositories. the <filename>README</filename> file) supplied with the layer.
</para></listitem> If in doubt, please ask on the Yocto general mailing list or on
</itemizedlist> the openembedded-devel mailing list.
Maintainers use these branches to test submissions prior to merging </para>
patches.
Thus, you can get an idea of the status of a patch based on
whether the patch has been merged into one of these branches.
</para>
<para> <para>
This system is imperfect and patches can sometimes get lost in the You can also push a change upstream and request a maintainer to
pull the change into the component's upstream repository.
You do this by pushing to a contribution repository that is upstream.
See the
"<ulink url='&YOCTO_DOCS_REF_URL;#workflows'>Workflows</ulink>"
section in the Yocto Project Reference Manual for additional
concepts on working in the Yocto Project development environment.
</para>
<para>
Two commonly used testing repositories exist for
OpenEmbedded-Core:
<itemizedlist>
<listitem><para>
<emphasis>"ross/mut" branch:</emphasis>
The "mut" (master-under-test) tree
exists in the <filename>poky-contrib</filename> repository
in the
<ulink url='&YOCTO_GIT_URL;'>Yocto Project source repositories</ulink>.
</para></listitem>
<listitem><para>
<emphasis>"master-next" branch:</emphasis>
This branch is part of the main
"poky" repository in the Yocto Project source repositories.
</para></listitem>
</itemizedlist>
Maintainers use these branches to test submissions prior to merging
patches.
Thus, you can get an idea of the status of a patch based on
whether the patch has been merged into one of these branches.
<note>
This system is imperfect and changes can sometimes get lost in the
flow. flow.
Asking about the status of a patch is reasonable if the patch Asking about the status of a patch or change is reasonable if the
has been idle for a while with no feedback. change has been idle for a while with no feedback.
The Yocto Project does have plans to use The Yocto Project does have plans to use
<ulink url='https://en.wikipedia.org/wiki/Patchwork_(software)'>Patchwork</ulink> <ulink url='https://en.wikipedia.org/wiki/Patchwork_(software)'>Patchwork</ulink>
to track the status of patches and also to automatically preview to track the status of patches and also to automatically preview
patches. patches.
</para> </note>
</para>
<para>
The following sections provide procedures for submitting a change.
</para>
<section id='pushing-a-change-upstream'>
<title>Using Scripts to Push a Change Upstream and Request a Pull</title>
<para> <para>
The following sections provide general instructions for both Follow this procedure to push a change to an upstream "contrib"
pushing changes upstream and for submitting changes as patches. Git repository:
</para>
</section>
<section id='submit-change-submissions-to-poky'>
<title>Submissions to Poky</title>
<para>
The "poky" repository, which is the Yocto Project's reference build
environment, is a hybrid repository that contains several
individual pieces (e.g. BitBake, OpenEmbedded-Core, meta-yocto,
documentation, and so forth) built using the combo-layer tool.
The upstream location used for submitting changes varies by
component:
<itemizedlist>
<listitem><para>
<emphasis>Core Metadata:</emphasis>
Send your patch to the
<ulink url='http://lists.openembedded.org/mailman/listinfo/openembedded-core'>openembedded-core</ulink>
mailing list. For example, a change to anything under
the <filename>meta</filename> or
<filename>scripts</filename> directories should be sent
to this mailing list.
</para></listitem>
<listitem><para>
<emphasis>BitBake:</emphasis>
For changes to BitBake (i.e. anything under the
<filename>bitbake</filename> directory), send your patch
to the
<ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'>bitbake-devel</ulink>
mailing list.
</para></listitem>
<listitem><para>
<emphasis>"meta-yocto-bsp" and "meta-poky" trees:</emphasis>
These trees are
part of the "meta-yocto" repository in the Yocto Project
source repositories.
Use the
<ulink url='https://lists.yoctoproject.org/listinfo/poky'>poky</ulink>
mailing list.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='submit-change-submissions-to-other-layers'>
<title>Submissions to Other Layers</title>
<para>
For changes to other layers hosted in the Yocto Project source
repositories (i.e. <filename>yoctoproject.org</filename>), tools,
and the Yocto Project documentation, use the
<ulink url='https://lists.yoctoproject.org/listinfo/yocto'>Yocto Project</ulink>
general mailing list.
<note> <note>
Sometimes a layer's documentation specifies to use a You can find general Git information on how to push a change
particular mailing list. upstream in the
If so, use that list. <ulink url='http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows'>Git Community Book</ulink>.
</note> </note>
For additional recipes that do not fit into the core Metadata, you <orderedlist>
should determine which layer the recipe should go into and submit
the change in the manner recommended by the documentation (e.g.
the <filename>README</filename> file) supplied with the layer.
If in doubt, please ask on the Yocto general mailing list or on
the openembedded-devel mailing list.
</para>
</section>
<section id='submit-change-patch-submission-details'>
<title>Patch Submission Details</title>
<para>
When submitting any change, you can check who you should be
notifying.
Use either of these methods to find out:
<itemizedlist>
<listitem><para> <listitem><para>
<emphasis>Maintenance File:</emphasis> <emphasis>Make Your Changes Locally:</emphasis>
Examine the <filename>maintainers.inc</filename> file, which is Make your changes in your local Git repository.
located in the You should make small, controlled, isolated changes.
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink> Keeping changes small and isolated aids review,
at <filename>meta-poky/conf/distro/include</filename>, to makes merging/rebasing easier and keeps the change
see who is responsible for code. history clean should anyone need to refer to it in
future.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis>Search by File:</emphasis> <emphasis>Stage Your Changes:</emphasis>
Using <ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>, you can enter the Stage your changes by using the <filename>git add</filename>
following command to bring up a short list of all commits command on each file you changed.
against a specific file:
<literallayout class='monospaced'>
git shortlog -- <replaceable>filename</replaceable>
</literallayout>
Just provide the name of the file for which you are interested.
The information returned is not ordered by history but does
include a list of everyone who has committed grouped by
name.
From the list, you can see who is responsible for the bulk of
the changes against the file.
</para></listitem> </para></listitem>
</itemizedlist> <listitem><para id='making-sure-you-have-correct-commit-information'>
</para> <emphasis>Commit Your Changes:</emphasis>
Commit the change by using the
<para> <filename>git commit</filename> command.
For a list of the Yocto Project and related mailing lists, see the Make sure your commit information follows standards by
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" following these accepted conventions:
section in the Yocto Project Reference Manual. <itemizedlist>
</para> <listitem><para>
Be sure to include a "Signed-off-by:" line in the
<para> same style as required by the Linux kernel.
When you send a patch, be sure to include a "Signed-off-by:" Adding this line signifies that you, the submitter,
line in the same style as required by the Linux kernel. have agreed to the Developer's Certificate of
Adding this line signifies that you, the submitter, have agreed Origin 1.1 as follows:
to the Developer's Certificate of Origin 1.1 as follows: <literallayout class='monospaced'>
<literallayout class='monospaced'>
Developer's Certificate of Origin 1.1 Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that: By making a contribution to this project, I certify that:
@@ -652,121 +643,133 @@
personal information I submit with it, including my sign-off) is personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved. this project or the open source license(s) involved.
</literallayout> </literallayout>
</para> </para></listitem>
<listitem><para>
<para> Provide a single-line summary of the change.
In a collaborative environment, it is necessary to have some sort and,
of standard or method through which you submit changes. if more explanation is needed, provide more
Otherwise, things could get quite chaotic. detail in the body of the commit.
One general practice to follow is to make small, controlled changes. This summary is typically viewable in the
Keeping changes small and isolated aids review, makes "shortlist" of changes.
merging/rebasing easier and keeps the change history clean should Thus, providing something short and descriptive
anyone need to refer to it in future. that gives the reader a summary of the change is
</para> useful when viewing a list of many commits.
You should prefix this short description with the
<para> recipe name (if changing a recipe), or else with
When you make a commit, you must follow certain standards the short form path to the file being changed.
established by the OpenEmbedded and Yocto Project development teams. </para></listitem>
For each commit, you must provide a single-line summary of the <listitem><para>
change and you should almost always provide a more detailed For the body of the commit message, provide
description of what you did (i.e. the body of the commit message). detailed information that describes what you
The only exceptions for not providing a detailed description would changed, why you made the change, and the approach
be if your change is a simple, self-explanatory change that needs you used.
no further description beyond the summary. It might also be helpful if you mention how you
Here are the guidelines for composing a commit message: tested the change.
<itemizedlist> Provide as much detail as you can in the body of
<listitem><para> the commit message.
Provide a single-line, short summary of the change. <note>
This summary is typically viewable in the "shortlist" of You do not need to provide a more detailed
changes. explanation of a change if the change is
Thus, providing something short and descriptive that minor to the point of the single line
gives the reader a summary of the change is useful when summary providing all the information.
viewing a list of many commits. </note>
You should prefix this short description with the recipe </para></listitem>
name (if changing a recipe), or else with the short form <listitem><para>
path to the file being changed. If the change addresses a specific bug or issue
</para></listitem> that is associated with a bug-tracking ID,
<listitem><para> include a reference to that ID in your detailed
For the body of the commit message, provide detailed description.
information that describes what you changed, why you made For example, the Yocto Project uses a specific
the change, and the approach you used. convention for bug references - any commit that
It might also be helpful if you mention how you tested addresses a specific bug should use the following
the change. form for the detailed description.
Provide as much detail as you can in the body of the Be sure to use the actual bug-tracking ID from
commit message. Bugzilla for
</para></listitem> <replaceable>bug-id</replaceable>:
<listitem><para> <literallayout class='monospaced'>
If the change addresses a specific bug or issue that is
associated with a bug-tracking ID, include a reference
to that ID in your detailed description.
For example, the Yocto Project uses a specific convention
for bug references - any commit that addresses a specific
bug should use the following form for the detailed
description.
Be sure to use the actual bug-tracking ID from
Bugzilla for
<replaceable>bug-id</replaceable>:
<literallayout class='monospaced'>
Fixes [YOCTO #<replaceable>bug-id</replaceable>] Fixes [YOCTO #<replaceable>bug-id</replaceable>]
<replaceable>detailed description of change</replaceable> <replaceable>detailed description of change</replaceable>
</literallayout> </literallayout>
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
</para>
<para>
You can find more guidance on creating well-formed commit messages
at this OpenEmbedded wiki page:
<ulink url='&OE_HOME_URL;/wiki/Commit_Patch_Message_Guidelines'></ulink>.
</para>
</section>
<section id='pushing-a-change-upstream'>
<title>Using Scripts to Push a Change Upstream and Request a Pull</title>
<para>
The basic flow for pushing a change to an upstream "contrib" Git repository is as follows:
<itemizedlist>
<listitem><para>Make your changes in your local Git repository.</para></listitem>
<listitem><para>Stage your changes by using the <filename>git add</filename>
command on each file you changed.</para></listitem>
<listitem><para>
Commit the change by using the
<filename>git commit</filename> command.
Be sure to provide a commit message that follows the
project’s commit message standards as described earlier.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis>Push Your Commits to a "Contrib" Upstream:</emphasis>
Push the change to the upstream "contrib" repository by Push the change to the upstream "contrib" repository by
using the <filename>git push</filename> command. using the <filename>git push</filename> command.
</para></listitem> </para></listitem>
<listitem><para>Notify the maintainer that you have pushed a change by making a pull <listitem><para id='push-determine-who-to-notify'>
request. <emphasis>Determine Who to Notify:</emphasis>
The Yocto Project provides two scripts that conveniently let you generate and send Determine the maintainer that you need to notify for
pull requests to the Yocto Project. the change.</para>
These scripts are <filename>create-pull-request</filename> and
<filename>send-pull-request</filename>. <para>Before submitting any change, you need to be sure
You can find these scripts in the <filename>scripts</filename> directory who the maintainer is that you need to notify.
within the <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.</para> Use either of these methods to find out:
<para>Using these scripts correctly formats the requests without introducing any <itemizedlist>
whitespace or HTML formatting. <listitem><para>
The maintainer that receives your patches needs to be able to save and apply them <emphasis>Maintenance File:</emphasis>
directly from your emails. Examine the <filename>maintainers.inc</filename>
Using these scripts is the preferred method for sending patches.</para> file, which is located in the
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
at
<filename>meta-poky/conf/distro/include</filename>,
to see who is responsible for code.
</para></listitem>
<listitem><para>
<emphasis>Search by File:</emphasis>
Using <ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>,
you can enter the following command to bring up a
short list of all commits against a specific file:
<literallayout class='monospaced'>
git shortlog -- <replaceable>filename</replaceable>
</literallayout>
Just provide the name of the file for which you
are interested.
The information returned is not ordered by history
but does include a list of everyone who has
committed grouped by name.
From the list, you can see who is responsible for
the bulk of the changes against the file.
</para></listitem>
</itemizedlist>
For a list of the Yocto Project and related mailing lists,
see the
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>"
section in the Yocto Project Reference Manual.
</para></listitem>
<listitem><para>
<emphasis>Make a Pull Request:</emphasis>
Notify the maintainer that you have pushed a change by
making a pull request.</para>
<para>The Yocto Project provides two scripts that
conveniently let you generate and send pull requests to the
Yocto Project.
These scripts are <filename>create-pull-request</filename>
and <filename>send-pull-request</filename>.
You can find these scripts in the
<filename>scripts</filename> directory within the
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
</para>
<para>Using these scripts correctly formats the requests
without introducing any whitespace or HTML formatting.
The maintainer that receives your patches needs to be
able to save and apply them directly from your emails.
Using these scripts is the preferred method for sending
patches.</para>
<para>For help on using these scripts, simply provide the <para>For help on using these scripts, simply provide the
<filename>-h</filename> argument as follows: <filename>-h</filename> argument as follows:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ poky/scripts/create-pull-request -h $ poky/scripts/create-pull-request -h
$ poky/scripts/send-pull-request -h $ poky/scripts/send-pull-request -h
</literallayout></para></listitem> </literallayout>
</itemizedlist> </para></listitem>
</para> </orderedlist>
<para>
You can find general Git information on how to push a change upstream in the
<ulink url='http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows'>Git Community Book</ulink>.
</para> </para>
</section> </section>
@@ -774,49 +777,63 @@
<title>Using Email to Submit a Patch</title> <title>Using Email to Submit a Patch</title>
<para> <para>
You can submit patches without using the <filename>create-pull-request</filename> and You can submit patches without using the
<filename>send-pull-request</filename> scripts described in the previous section. <filename>create-pull-request</filename> and
<filename>send-pull-request</filename> scripts described in the
previous section.
However, keep in mind, the preferred method is to use the scripts. However, keep in mind, the preferred method is to use the scripts.
</para> </para>
<para> <para>
Depending on the components changed, you need to submit the email Depending on the components changed, you need to submit the email
to a specific mailing list. to a specific mailing list.
For some guidance on which mailing list to use, see the list in the For some guidance on which mailing list to use, see the
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" <link linkend='figuring-out-the-mailing-list-to-use'>beginning</link>
section. of this section.
For a description of the available mailing lists, see the For a description of all the available mailing lists, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>" "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
section in the Yocto Project Reference Manual. section in the Yocto Project Reference Manual.
</para> </para>
<para> <para>
Here is the general procedure on how to submit a patch through email without using the Here is the general procedure on how to submit a patch through
scripts: email without using the scripts:
<orderedlist> <orderedlist>
<listitem><para> <listitem><para>
<emphasis>Make Your Changes Locally:</emphasis>
Make your changes in your local Git repository. Make your changes in your local Git repository.
You should make small, controlled, isolated changes.
Keeping changes small and isolated aids review,
makes merging/rebasing easier and keeps the change
history clean should anyone need to refer to it in
future.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Stage your changes by using the <emphasis>Stage Your Changes:</emphasis>
<filename>git add</filename> command on each file you Stage your changes by using the <filename>git add</filename>
changed. command on each file you changed.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis>Commit Your Changes:</emphasis>
Commit the change by using the Commit the change by using the
<filename>git commit --signoff</filename> command. <filename>git commit --signoff</filename> command.
Using the <filename>--signoff</filename> option identifies Using the <filename>--signoff</filename> option identifies
you as the person making the change and also satisfies you as the person making the change and also satisfies
the Developer's Certificate of Origin (DCO) shown earlier. the Developer's Certificate of Origin (DCO) shown earlier.
</para> </para>
<para>When you form a commit, you must follow certain <para>When you form a commit, you must follow certain
standards established by the Yocto Project development standards established by the Yocto Project development
team. team.
See the earlier section See
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" <link linkend='making-sure-you-have-correct-commit-information'>Step 3</link>
for Yocto Project commit message standards. in the previous section for information on how to
provide commit information that meets Yocto Project
commit message standards.
</para></listitem> </para></listitem>
<listitem><para>Format the commit into an email message. <listitem><para>
<emphasis>Format the Commit:</emphasis>
Format the commit into an email message.
To format commits, use the To format commits, use the
<filename>git format-patch</filename> command. <filename>git format-patch</filename> command.
When you provide the command, you must include a revision When you provide the command, you must include a revision
@@ -831,9 +848,11 @@
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ git format-patch HEAD~ $ git format-patch HEAD~
</literallayout></para> </literallayout></para>
<para>After the command is run, the current directory <para>After the command is run, the current directory
contains a numbered <filename>.patch</filename> file for contains a numbered <filename>.patch</filename> file for
the commit.</para> the commit.</para>
<para>If you provide several commits as part of the <para>If you provide several commits as part of the
command, the <filename>git format-patch</filename> command command, the <filename>git format-patch</filename> command
produces a series of numbered files in the current produces a series of numbered files in the current
@@ -857,6 +876,7 @@
</note> </note>
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis>Import the Files Into Your Mail Client:</emphasis>
Import the files into your mail client by using the Import the files into your mail client by using the
<filename>git send-email</filename> command. <filename>git send-email</filename> command.
<note> <note>
@@ -866,6 +886,7 @@
For Ubuntu, Debian, and Fedora the package is For Ubuntu, Debian, and Fedora the package is
<filename>git-email</filename>. <filename>git-email</filename>.
</note></para> </note></para>
<para>The <filename>git send-email</filename> command <para>The <filename>git send-email</filename> command
sends email by using a local or remote Mail Transport Agent sends email by using a local or remote Mail Transport Agent
(MTA) such as <filename>msmtp</filename>, (MTA) such as <filename>msmtp</filename>,
@@ -882,6 +903,7 @@
applicable by the maintainer is to do a dry run and send applicable by the maintainer is to do a dry run and send
them to yourself and then save and apply them as the them to yourself and then save and apply them as the
maintainer would.</para> maintainer would.</para>
<para>The <filename>git send-email</filename> command is <para>The <filename>git send-email</filename> command is
the preferred method for sending your patches since there the preferred method for sending your patches since there
is no risk of compromising whitespace in the body of the is no risk of compromising whitespace in the body of the