From 2c07c66cf1be3a8aad70f34fff32592a96c5df41 Mon Sep 17 00:00:00 2001 From: Darren Salt Date: Thu, 15 Jan 2009 15:29:13 +0000 Subject: Document patch submission preferences. --- doc/hackersguide/overview.sgml | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'doc/hackersguide') diff --git a/doc/hackersguide/overview.sgml b/doc/hackersguide/overview.sgml index d405ac18c..c8d15a4f9 100644 --- a/doc/hackersguide/overview.sgml +++ b/doc/hackersguide/overview.sgml @@ -806,6 +806,32 @@ working on other parts of the code or are simply busy at the moment). + + We prefer to receive patches in a format which is immediately + committable. This normally means that we want your name and email address + (we're not keen on pseudonyms), a subject line which provides a + convenient summary of your changes, and body text which provides a longer + description (if needed). Patches must be generated using hg + diff or cvs -z9 diff, depending on which is + used for the repository, and always from within the top level of the + checked-out source. + + + If your patch is intended for a Mercurial-format repository, then + committing it locally and using + hg export . >foo.patch + to create the file to be attached is acceptable (but note that the first + line - up to the first line feed - of the commit message is regarded as + the patch summary; if you're not sure, check with + hg log -r.. + Alternatively, use From: and Subject: lines + in the patch file itself; this is useful when forwarding. + + + Patches should normally be included as attachments. Some mail clients and + webmail services are known to mangle whitespace or wrap lines, either of + which is enough to render a patch potentially useless. + -- cgit v1.2.3