[libvirt] [PATCH] docs: Improve patch submission guidelines
Michal Privoznik
mprivozn at redhat.com
Mon Jul 9 08:26:25 UTC 2012
On 09.07.2012 10:15, Michal Privoznik wrote:
> We should really advise (new) developers to send rebased patches
> that apply cleanly and use git-send-email rather than all other
> obscure ways.
> ---
> docs/hacking.html.in | 30 +++++++++++++++++++++++++++---
> 1 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/docs/hacking.html.in b/docs/hacking.html.in
> index 89f9980..96859fd 100644
> --- a/docs/hacking.html.in
> +++ b/docs/hacking.html.in
> @@ -11,19 +11,43 @@
>
> <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>
> + 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 --to=libvir-list at redhat.com master
> +</pre>
> + 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.
> </li>
> +
> <li>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.
> + </li>
> +
huh, these <li/> I am touching should have really been
<li><p>...</p></li>. Fixed on my local branch.
Btw: what about this HACKING file? I mean it's autogenerated and watched
by git as well. Or do want new developers to read this file on bare
checkout before first build? I should have commited changes to this file
then too, shouldn't I?
More information about the libvir-list
mailing list