From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 12 Dec 2013 22:18:29 +0000 (-0800)
Subject: Merge branch 'rs/doc-submitting-patches'
X-Git-Tag: v1.9-rc0~75
X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/fca26a3430161ac959343868e7523fc76a4b642e?hp=-c

Merge branch 'rs/doc-submitting-patches'

* rs/doc-submitting-patches:
SubmittingPatches: document how to handle multiple patches
---

fca26a3430161ac959343868e7523fc76a4b642e
diff --combined Documentation/SubmittingPatches
index 705557689d,9d230b3eb2..e6d46edbe7
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@@ -65,20 -65,7 +65,20 @@@ feature does not trigger when it should
  test suite passes after your commit.  Do not forget to update the
  documentation to describe the updated behaviour.
  
 -Oh, another thing.  I am picky about whitespaces.  Make sure your
 +Speaking of the documentation, it is currently a liberal mixture of US
 +and UK English norms for spelling and grammar, which is somewhat
 +unfortunate.  A huge patch that touches the files all over the place
 +only to correct the inconsistency is not welcome, though.  Potential
 +clashes with other changes that can result from such a patch are not
 +worth it.  We prefer to gradually reconcile the inconsistencies in
 +favor of US English, with small and easily digestible patches, as a
 +side effect of doing some other real work in the vicinity (e.g.
 +rewriting a paragraph for clarity, while turning en_UK spelling to
 +en_US).  Obvious typographical fixes are much more welcomed ("teh ->
 +"the"), preferably submitted as independent patches separate from
 +other documentation changes.
 +
 +Oh, another thing.  We are picky about whitespaces.  Make sure your
  changes do not trigger errors with the sample pre-commit hook shipped
  in templates/hooks--pre-commit.  To help ensure this does not happen,
  run git diff --check on your changes before you commit.
@@@ -139,8 -126,15 +139,15 @@@ People on the Git mailing list need to 
  comment on the changes you are submitting.  It is important for
  a developer to be able to "quote" your changes, using standard
  e-mail tools, so that they may comment on specific portions of
- your code.  For this reason, all patches should be submitted
- "inline".  If your log message (including your name on the
+ your code.  For this reason, each patch should be submitted
+ "inline" in a separate message.
+ 
+ Multiple related patches should be grouped into their own e-mail
+ thread to help readers find all parts of the series.  To that end,
+ send them as replies to either an additional "cover letter" message
+ (see below), the first patch, or the respective preceding patch.
+ 
+ If your log message (including your name on the
  Signed-off-by line) is not writable in ASCII, make sure that
  you send off a message in the correct encoding.