External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 21:55:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

hacking: Improve 'git send-email' documentation

Browse Source 
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@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This commit is contained in:
Andrea Bolognani 2017-06-15 11:25:31 +08:00
parent 8ad01d5cc8
commit 79c1900fc1
1 changed files with 34 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
docs/hacking.html.in
View File

@ -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>
@ -50,22 +50,44 @@
git pull --rebase
(fix any conflicts)
git send-email --cover-letter --no-chain-reply-to --annotate \
--to=libvir-list@redhat.com master
--confirm=always --to=libvir-list@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
<p>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>--to=libvir-list@redhat.com</code> designation you can
set it in git config:</p>
patches needs a cover letter.</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>--to=libvir-list@redhat.com</code> all the time, you can
configure that to be automatically handled as well:</p>
<pre>
git config sendemail.to libvir-list@redhat.com
</pre>
<p>As a rule, patches should be sent to the mailing list only: all
developers are subscribed to libvir-list and read it regularly, so
please don't CC individual developers unless they've explicitly
asked you to.</p>
<p>Avoid using mail clients for sending patches, as most of them
will mangle the messages in some way, making them unusable for our
purposes. Gmail and other Web-based mail clients are particularly
bad at this.</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. Note
that your very first post to the mailing list will be subject to
moderation, and it's not uncommon for that to take around a day.</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.</p>
<p>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