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(a)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/ &gt; 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(a)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