René Genz <liebundar...@freenet.de> writes: > -use US English spelling > -minor wording change for better readability > > Helped-by: Stefan Beller <sbel...@google.com> > Signed-off-by: René Genz <liebundar...@freenet.de> > ---
Thanks, will apply. > Documentation/SubmittingPatches | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index bc8ad00..558d465 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -51,7 +51,7 @@ If your description starts to get too long, that's a sign > that you > probably need to split up your commit to finer grained pieces. > That being said, patches which plainly describe the things that > help reviewers check the patch, and future maintainers understand > -the code, are the most beautiful patches. Descriptions that summarise > +the code, are the most beautiful patches. Descriptions that summarize > the point in the subject well, and describe the motivation for the > change, the approach taken by the change, and if relevant how this > differs substantially from the prior version, are all good things > @@ -87,7 +87,7 @@ 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. > +run "git diff --check" on your changes before you commit. > > > (2) Describe your changes well. > @@ -111,10 +111,10 @@ Improve...". > > The body should provide a meaningful commit message, which: > > - . explains the problem the change tries to solve, iow, what is wrong > + . explains the problem the change tries to solve, i.e. what is wrong > with the current code without the change. > > - . justifies the way the change solves the problem, iow, why the > + . justifies the way the change solves the problem, i.e. why the > result with the change is better. > > . alternate solutions considered but discarded, if any. > @@ -122,7 +122,7 @@ The body should provide a meaningful commit message, > which: > Describe your changes in imperative mood, e.g. "make xyzzy do frotz" > instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy > to do frotz", as if you are giving orders to the codebase to change > -its behaviour. Try to make sure your explanation can be understood > +its behavior. Try to make sure your explanation can be understood > without external resources. Instead of giving a URL to a mailing list > archive, summarize the relevant points of the discussion. > > @@ -261,7 +261,7 @@ smaller project it is a good discipline to follow it. > The sign-off is a simple line at the end of the explanation for > the patch, which certifies that you wrote it or otherwise have > the right to pass it on as a open-source patch. The rules are > -pretty simple: if you can certify the below: > +pretty simple: if you can certify the below D-C-O: > > Developer's Certificate of Origin 1.1
