I can't think of any good reason to do either of those, and having the examples there will just lead to unusable patch emails from people who can't be bothered to read the entire page. --- I'm sure there are other problems with this file, but this one really jupmed out at me when I was suggesting to someone that they look to this page for proper procedures. docs/hacking.html.in | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/docs/hacking.html.in b/docs/hacking.html.in index a471d88..5f19143 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -23,21 +23,11 @@ automatically pulls the latest version of each translation file from zanata.</li> - <li><p>Post patches in unified diff format, with git rename + <li><p>Post patches using "git send-email", with git rename detection enabled. You need a one-time setup of:</p> <pre> git config diff.renames true </pre> - <p>After that, a command similar to this should work:</p> -<pre> - diff -urp libvirt.orig/ libvirt.modified/ &gt; libvirt-myfeature.patch -</pre> - <p> - or: - </p> -<pre> - git diff &gt; libvirt-myfeature.patch -</pre> <p>Also, for code motion patches, you may find that <code>git diff --patience</code> provides an easier-to-read patch. However, the usual workflow of libvirt developer is:</p>