[libvirt] [PATCHv2] docs: Improve patch submission guidelines

[Michal Privoznik]

We should really advise (new) developers to send rebased patches
that apply cleanly and use git-send-email rather than all other
obscure ways.
---
 HACKING              |   22 +++++++++++++++++++++-
 docs/hacking.html.in |   33 ++++++++++++++++++++++++++++-----
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/HACKING b/HACKING
index 69ea96b..def94ee 100644
--- a/HACKING
+++ b/HACKING
@@ -21,9 +21,29 @@ or:
 
   git diff > libvirt-myfeature.patch
 
+However, the usual workflow of libvirt developer is:  git checkout master
+  git pull
+  git checkout -b workbranch
+  Hack, committing any changes along the way
+
+Then, when you want to post your patches:  git checkout master
+  git pull
+  git checkout workbranch
+  git rebase master
+  (fix any conflicts)
+  git send-email --compose --to=libvir-list at redhat.com master
+
+Please follow this as close as you can, especially the rebase and git
+send-email part as it makes developer's, who is reviewing your patch set, life
+easier. One should avoid sending patches as attachment but rather send them in
+email body among with commit message.
+
 (3) Split large changes into a series of smaller patches, self-contained if
 possible, with an explanation of each patch and an explanation of how the
-sequence of patches fits together.
+sequence of patches fits together. Moreover, please keep in mind that it's
+required to be able to compile cleanly after each patch.
+
+
 
 (4) Make sure your patches apply against libvirt GIT. Developers only follow GIT
 and don't care much about released versions.
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 89f9980..af852e0 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -11,19 +11,42 @@
 
       <li><p>Post patches in unified diff format.  A command similar to this
         should work:</p>
-<pre>
+<del><pre>
   diff -urp libvirt.orig/ libvirt.modified/ > libvirt-myfeature.patch
-</pre>
+</pre></del>
         <p>
           or:
         </p>
 <pre>
   git diff > libvirt-myfeature.patch
 </pre>
-      </li>
-      <li>Split large changes into a series of smaller patches, self-contained
+        However, the usual workflow of libvirt developer is:
+<pre>
+  git checkout master
+  git pull
+  git checkout -b workbranch
+  Hack, committing any changes along the way
+</pre>
+        Then, when you want to post your patches:
+<pre>
+  git checkout master
+  git pull
+  git checkout workbranch
+  git rebase master
+  (fix any conflicts)
+  git send-email --compose --no-chain-reply-to --to=libvir-list at redhat.com master
+</pre>
+        <p>Please follow this as close as you can, especially the rebase and git
+        send-email part as it makes developer's, who is reviewing your patch
+        set, life easier. One should avoid sending patches as attachment but
+        rather send them in email body among with commit message.</p></li>
+
+      <li><p>Split large changes into a series of smaller patches, self-contained
         if possible, with an explanation of each patch and an explanation of how
-        the sequence of patches fits together.</li>
+        the sequence of patches fits together. Moreover, please keep in mind that
+        it's required to be able to compile cleanly after each patch.</p>
+      </li>
+
       <li>Make sure your patches apply against libvirt GIT.  Developers
         only follow GIT and don't care much about released versions.</li>
       <li><p>Run the automated tests on your code before submitting any changes.
-- 
1.7.8.6