diff options
Diffstat (limited to 'Documentation/SubmittingPatches')
| -rw-r--r-- | Documentation/SubmittingPatches | 27 |
1 files changed, 20 insertions, 7 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 90133d8c3b..705557689d 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -65,7 +65,20 @@ 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. -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. @@ -103,9 +116,9 @@ without external resources. Instead of giving a URL to a mailing list 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 @@ -122,7 +135,7 @@ that is fine, but please mark it as such. (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 @@ -206,7 +219,7 @@ patch. 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 @@ -244,7 +257,7 @@ then you just add a line saying 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 @@ -337,7 +350,7 @@ Know the status of your patch after submission 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. |