This will hopefully avoid questions over which spelling and grammar should
be used.  Translators are of course free to create localizations for other
specific English dialects.

Signed-off-by: Marc Branchaud <>

A little less stringent now.

 Documentation/CodingGuidelines  |  6 ++++++
 Documentation/SubmittingPatches | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 559d5f9..fc397f3 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -242,6 +242,12 @@ Writing Documentation:
  processed into HTML and manpages (e.g. git.html and git.1 in the
  same directory).
+ The documentation generally follows US English (en_US) norms for spelling
+ and grammar, although most spelling variations are tolerated.  Just avoid
+ mixing styles when updating existing text.  If you wish to correct the
+ English of some of the existing documentation, please see the documentation-
+ related advice in the Documentation/SubmittingPatches file.
  Every user-visible change should be reflected in the documentation.
  The same general rule as for code applies -- imitate the existing
  conventions.  A few commented examples follow to provide reference
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d0a4733..998e407 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -65,6 +65,16 @@ feature does not trigger when it shouldn't.  Also make sure 
that the
 test suite passes after your commit.  Do not forget to update the
 documentation to describe the updated behaviour.
+Speaking of the documentation, if you are attempting to correct typographical
+or grammatical errors use one patch for indisputably correct changes (e.g.
+"teh" -> "the") and put subjective/stylistic changes in a separate patch.
+This helps to streamline reviews of your patches.  Also, although the
+documentation is mainly written in US English, most non-US spelling variants
+are acceptable.  Patches that change one common spelling to another (such as
+changing "behaviour" to "behavior") are generally not helpful, as
+oftentimes a few months later some generous soul will want to change the
+spelling the other way.
 Oh, another thing.  I am 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,

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to