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.
archive, summarize the relevant points of the discussion.
-(3) Generate your patch using git tools out of your commits.
+(3) Generate your patch using Git tools out of your commits.
-git based diff tools generate unidiff which is the preferred format.
+Git based diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
(4) Sending your patches.
-People on the git mailing list need to be able to read and
+People on the Git mailing list need to be able to read and
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.
To improve tracking of who did what, we've borrowed the
"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around. Although core GIT is a lot
+that are being emailed around. Although core Git is a lot
smaller project it is a good discipline to follow it.
The sign-off is a simple line at the end of the explanation for
Signed-off-by: Random J Developer <random@developer.example.org>
-This line can be automatically added by git if you run the git-commit
+This line can be automatically added by Git if you run the git-commit
command with the -s option.
Notice that you can place your own Signed-off-by: line when
tell you if your patch is merged in pu if you rebase on top of
master).
-* Read the git mailing list, the maintainer regularly posts messages
+* Read the Git mailing list, the maintainer regularly posts messages
entitled "What's cooking in git.git" and "What's in git.git" giving
the status of various proposed changes.