For the benefit of first time contributors, we point out that 'git send-email' might have to be installed separately; however, we omit the fact that some configuration will likely be needed before it can successfully deliver patches to the mailing list. Some minor tweaks to the existing contents are included as well. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com&gt; --- docs/hacking.html.in | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/docs/hacking.html.in b/docs/hacking.html.in index d6a574c..434fb68 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -29,8 +29,8 @@ file from zanata.</p> </li> - <li><p>Post patches using "git send-email", with git rename - detection enabled. You need a one-time setup of:</p> + <li><p>Post patches using <code>git send-email</code>, with git + rename detection enabled. You need a one-time setup of:</p> <pre> git config diff.renames true </pre> @@ -52,20 +52,32 @@ git send-email --cover-letter --no-chain-reply-to --annotate \ --to=libvir-list(a)redhat.com master </pre> - <p>(Note that the "git send-email" subcommand may not be in - the main git package and using it may require installation of a - separate package, for example the "git-email" package in - Fedora.) For a single patch you can omit - <code>--cover-letter</code>, but a series of two or more - patches needs a cover letter. If you get tired of typing - <code&gt;--to=libvir-list(a)redhat.com&lt;/code&gt; designation you can - set it in git config:</p> + <p>Note that the <code>git send-email</code> subcommand may not + be in the main git package and using it may require installation + of a separate package, for example the "git-email" package in + Fedora and Debian. If this is your first time using + <code>git send-email</code>, you might need to configure it to + point it to your SMTP server with something like:</p> +<pre> + git config --global sendemail.smtpServer stmp.youremailprovider.net +</pre> + <p>If you get tired of typing + <code&gt;--to=libvir-list(a)redhat.com&lt;/code&gt; all the time, you can + configure that to be automatically handled as well:</p> <pre> git config sendemail.to libvir-list(a)redhat.com </pre> + <p>For a single patch you can omit + <code>--cover-letter</code>, but a series of two or more + patches needs a cover letter.</p> + <p>If everything went well, your patch should show up on the + <a href="https://www.redhat.com/archives/libvir-list/">libvir-list + archives</a> in a matter of minutes; if you still can't find it on + there after an hour or so, you should double-check your setup.</p> <p>Please follow this as close as you can, especially the rebase and - git send-email part, as it makes life easier for other developers to - review your patch set. One should avoid sending patches as attachments, + <code>git send-email</code> part, as it makes life easier for other + developers to review your patch set. + One should avoid sending patches as attachments, but rather send them in email body along with commit message. If a developer is sending another version of the patch (e.g. to address review comments), they are advised to note differences to previous -- 2.7.5