From f29a05dd856bc38977866a4ac41c87ba6af6e3d0 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 7 Jun 2017 09:14:52 -0700 Subject: dev-manual: Formed ordered list for email patch procedure The section that describes how to create a patch and send it via email is really an ordered procedure. I recast the list of steps using numbers instead of bullets. (From yocto-docs rev: c2d2256ca6d8c8b837bae87a5bd8a3118553935c) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-newbie.xml | 137 +++++++++++++++---------- 1 file changed, 83 insertions(+), 54 deletions(-) (limited to 'documentation/dev-manual/dev-manual-newbie.xml') diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 4fd0d3a60c..2a62fd96c6 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -1722,8 +1722,8 @@ - Depending on the components changed, you need to submit the email to a specific - mailing list. + Depending on the components changed, you need to submit the email + to a specific mailing list. For some guidance on which mailing list to use, see the list in the "How to Submit a Change" section. @@ -1735,24 +1735,34 @@ Here is the general procedure on how to submit a patch through email without using the scripts: - - Make your changes in your local Git repository. - Stage your changes by using the git add - command on each file you changed. - Commit the change by using the + + + Make your changes in your local Git repository. + + + Stage your changes by using the + git add command on each file you + changed. + + + Commit the change by using the git commit --signoff command. - Using the --signoff option identifies you as the person - making the change and also satisfies the Developer's Certificate of - Origin (DCO) shown earlier. - When you form a commit, you must follow certain standards established by the - Yocto Project development team. + Using the --signoff option identifies + you as the person making the change and also satisfies + the Developer's Certificate of Origin (DCO) shown earlier. + + When you form a commit, you must follow certain + standards established by the Yocto Project development + team. See the earlier section "How to Submit a Change" - for Yocto Project commit message standards. + for Yocto Project commit message standards. + Format the commit into an email message. - To format commits, use the git format-patch command. - When you provide the command, you must include a revision list or a number of patches - as part of the command. + To format commits, use the + git format-patch command. + When you provide the command, you must include a revision + list or a number of patches as part of the command. For example, either of these two commands takes your most recent single commit and formats it as an email message in the current directory: @@ -1763,50 +1773,69 @@ $ git format-patch HEAD~ - After the command is run, the current directory contains a - numbered .patch file for the commit. - If you provide several commits as part of the command, - the git format-patch command produces a - series of numbered files in the current directory – one for each commit. + After the command is run, the current directory + contains a numbered .patch file for + the commit. + If you provide several commits as part of the + command, the git format-patch command + produces a series of numbered files in the current + directory – one for each commit. If you have more than one patch, you should also use the - --cover option with the command, which generates a - cover letter as the first "patch" in the series. - You can then edit the cover letter to provide a description for - the series of patches. - For information on the git format-patch command, - see GIT_FORMAT_PATCH(1) displayed using the - man git-format-patch command. - If you are or will be a frequent contributor to the Yocto Project - or to OpenEmbedded, you might consider requesting a contrib area and the - necessary associated rights. - Import the files into your mail client by using the + --cover option with the command, + which generates a cover letter as the first "patch" in + the series. + You can then edit the cover letter to provide a + description for the series of patches. + For information on the + git format-patch command, + see GIT_FORMAT_PATCH(1) displayed + using the man git-format-patch + command. + + If you are or will be a frequent contributor to the + Yocto Project or to OpenEmbedded, you might consider + requesting a contrib area and the necessary associated + rights. + + + + Import the files into your mail client by using the git send-email command. - In order to use git send-email, you must have the - the proper Git packages installed. - For Ubuntu, Debian, and Fedora the package is git-email. - The git send-email command sends email by using a local - or remote Mail Transport Agent (MTA) such as - msmtp, sendmail, or through a direct - smtp configuration in your Git config - file. - If you are submitting patches through email only, it is very important - that you submit them without any whitespace or HTML formatting that - either you or your mailer introduces. - The maintainer that receives your patches needs to be able to save and - apply them directly from your emails. - A good way to verify that what you are sending will be applicable by the - maintainer is to do a dry run and send them to yourself and then - save and apply them as the maintainer would. - The git send-email command is the preferred method - for sending your patches since there is no risk of compromising whitespace - in the body of the message, which can occur when you use your own mail client. + + In order to use git send-email, + you must have the proper Git packages installed. + For Ubuntu, Debian, and Fedora the package is + git-email. + + The git send-email command + sends email by using a local or remote Mail Transport Agent + (MTA) such as msmtp, + sendmail, or through a direct + smtp configuration in your Git + config file. + If you are submitting patches through email only, it is + very important that you submit them without any whitespace + or HTML formatting that either you or your mailer + introduces. + The maintainer that receives your patches needs to be able + to save and apply them directly from your emails. + A good way to verify that what you are sending will be + applicable by the maintainer is to do a dry run and send + them to yourself and then save and apply them as the + maintainer would. + The git send-email command is + the preferred method for sending your patches since there + is no risk of compromising whitespace in the body of the + message, which can occur when you use your own mail client. The command also has several options that let you - specify recipients and perform further editing of the email message. - For information on how to use the git send-email command, + specify recipients and perform further editing of the + email message. + For information on how to use the + git send-email command, see GIT-SEND-EMAIL(1) displayed using the man git-send-email command. - + -- cgit v1.2.3-54-g00ecf