doc: update SubmittingPatches
-use US English spelling -minor wording change for better readability Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: René Genz <liebundartig@freenet.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Genz committed
Apr 30, 2017 at 17:42 UTC
01e60a9a22fea0d10fe869b36d406b2eac131476
1 file changed
+6
-6
Documentation/SubmittingPatches
+6
-6
@@ -51,7 +51,7 @@ If your description starts to get too long, that's a sign that you
51
probably need to split up your commit to finer grained pieces.
52
That being said, patches which plainly describe the things that
53
help reviewers check the patch, and future maintainers understand
54
-the code, are the most beautiful patches. Descriptions that summarise
54
+the code, are the most beautiful patches. Descriptions that summarize
55
the point in the subject well, and describe the motivation for the
56
change, the approach taken by the change, and if relevant how this
57
differs substantially from the prior version, are all good things
@@ -87,7 +87,7 @@ patches separate from other documentation changes.
87
Oh, another thing. We are picky about whitespaces. Make sure your
88
changes do not trigger errors with the sample pre-commit hook shipped
89
in templates/hooks--pre-commit. To help ensure this does not happen,
90
-run git diff --check on your changes before you commit.
90
+run "git diff --check" on your changes before you commit.
91
92
93
(2) Describe your changes well.
@@ -106,10 +106,10 @@ files you are modifying to see the current conventions.
106
107
The body should provide a meaningful commit message, which:
108
109
- . explains the problem the change tries to solve, iow, what is wrong
109
+ . explains the problem the change tries to solve, i.e. what is wrong
110
with the current code without the change.
111
112
- . justifies the way the change solves the problem, iow, why the
112
+ . justifies the way the change solves the problem, i.e. why the
113
result with the change is better.
114
115
. alternate solutions considered but discarded, if any.
@@ -117,7 +117,7 @@ The body should provide a meaningful commit message, which:
117
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
118
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
119
to do frotz", as if you are giving orders to the codebase to change
120
-its behaviour. Try to make sure your explanation can be understood
120
+its behavior. Try to make sure your explanation can be understood
121
without external resources. Instead of giving a URL to a mailing list
122
archive, summarize the relevant points of the discussion.
123
@@ -255,7 +255,7 @@ smaller project it is a good discipline to follow it.
255
The sign-off is a simple line at the end of the explanation for
256
the patch, which certifies that you wrote it or otherwise have
257
the right to pass it on as a open-source patch. The rules are
258
-pretty simple: if you can certify the below:
258
+pretty simple: if you can certify the below D-C-O:
259
260
Developer's Certificate of Origin 1.1
261