minor typo in documentation - surplus 'a'

[René Genz]

Dear sir or madam,

I noticed a minor typo in `man 1 git-commit`.
There are two consecutive 'a'. At:
https://github.com/git/git/blob/maint/Documentation/git-commit.txt#L97
you can read:
---8<---
--reset-author::
When used with -C/-c/--amend options, or when committing after a
a conflicting ...
---8<---

Please, remove one 'a'.



I searched the code for another occurrence with:
git-maint$ for F in $(find . -type f); do grep -o "a_[[:space:]]a" <(paste -sd_ 
$F) | tr -d '_' ; done
a   a
a   a

One is in Documentation.
The other is from a test file, no change needed there:
https://github.com/git/git/blob/maint/t/t3904-stash-patch.sh#L94


Thank you in advance.
Have fun.
--
Kind regards,
René

minor typos in documentation

[René Genz]

Dear sir or madam,

At:
https://git-scm.com/docs/git-commit#git-commit---long

you can read:
When doing a dry-run, give the output in a the long-format.

From my point of view it should read:
When doing a dry-run, give the output in the long-format.



Furthermore in the file:
./Documentation/gitremote-helpers.txt

you can read:
As the a push option

It should be changed to:
As the push option



Additionally in the file:
./ci/run-windows-build.sh

please change:
# Script to trigger the a Git for Windows build and test run.

to:
# Script to trigger the Git for Windows build and test run.



And in the file:
./diff.c

change:
 *   1. collect a the minus/plus lines of a diff hunk, divided into

to:
 *   1. collect the minus/plus lines of a diff hunk, divided into

Thanks a lot in advance for fixing these minor typos.
--
Kind regards,
René

Re: minor typos in documentation

[René Genz]

On 19.04.2017 22:55, Stefan Beller wrote:
...


Thanks for spotting the errors!

Care to craft a patch and send it upstream yourself?
See https://github.com/git/git/blob/master/Documentation/SubmittingPatches
how to approach it.
TL;DR:
git clone https://github.com/git/git
# hack hack hack
git commit
git format-patch HEAD^
# use e.g. git send-email to send the patch to the mailing list

Thanks,
Stefan




To be honest I started to read the mentioned website, was intimidated and 
decided to sent an email.

Alright, what could possibly go wrong? I will do it.
--
Kind regards,
René

[PATCH] fix minor typing mistakes

[René Genz]

Thanks-to: Stefan Beller 
---
 Documentation/git-commit.txt| 4 ++--
 Documentation/gitremote-helpers.txt | 2 +-
 ci/run-windows-build.sh | 2 +-
 diff.c  | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index ed0f5b9..afb06ad 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -95,7 +95,7 @@ OPTIONS
 
 --reset-author::
When used with -C/-c/--amend options, or when committing after a
-   a conflicting cherry-pick, declare that the authorship of the
+   conflicting cherry-pick, declare that the authorship of the
resulting commit now belongs to the committer. This also renews
the author timestamp.
 
@@ -112,7 +112,7 @@ OPTIONS
`--dry-run`.
 
 --long::
-   When doing a dry-run, give the output in a the long-format.
+   When doing a dry-run, give the output in the long-format.
Implies `--dry-run`.
 
 -z::
diff --git a/Documentation/gitremote-helpers.txt 
b/Documentation/gitremote-helpers.txt
index e4b785e..4a584f3 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -463,7 +463,7 @@ set by Git if the remote helper has the 'option' capability.
GPG sign pushes.
 
 'option push-option ::
-   Transmit  as a push option. As the a push option
+   Transmit  as a push option. As the push option
must not contain LF or NUL characters, the string is not encoded.
 
 SEE ALSO
diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh
index 4e3a50b..9f89d54 100755
--- a/ci/run-windows-build.sh
+++ b/ci/run-windows-build.sh
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# Script to trigger the a Git for Windows build and test run.
+# Script to trigger the Git for Windows build and test run.
 # Set the $GFW_CI_TOKEN as environment variable.
 # Pass the branch (only branches on https://github.com/git/git are
 # supported) and a commit hash.
diff --git a/diff.c b/diff.c
index 11eef1c..74283d9 100644
--- a/diff.c
+++ b/diff.c
@@ -911,7 +911,7 @@ static int fn_out_diff_words_write_helper(FILE *fp,
 /*
  * '--color-words' algorithm can be described as:
  *
- *   1. collect a the minus/plus lines of a diff hunk, divided into
+ *   1. collect the minus/plus lines of a diff hunk, divided into
  *  minus-lines and plus-lines;
  *
  *   2. break both minus-lines and plus-lines into words and
-- 
1.9.1

[PATCH] doc: update SubmittingPatches

[René Genz]

-use US English spelling
-based on my own experience:
 * add commands used to contribute a patch
 * minor wording change for better readability

Thanks-to: Stefan Beller 
---
 Documentation/SubmittingPatches | 31 +--
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index bc8ad00..ac027ba 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
 
@@ -376,6 +376,25 @@ from the list and queue it to 'pu', in order to make it 
easier for
 people play with it without having to pick up and apply the patch to
 their trees themselves.
 
+
+An oversimplified summary of the commands to run:
+* clone repo
+  $ git clone https://github.com/git/git
+
+* change files in your local repo copy
+
+* commit your changes
+  $ git commit -a
+
+* create '.patch' file for the latest commit
+  $ git format-patch HEAD^
+
+* install 'git-email' package and configure it, f.e.
+https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/
+  send an email to yourself using your MUA in order to find out the value
+  for the "--smtp-domain" option; look at the 'Received' header option
+  $ git send-email --annotate --smtp-domain=LONGSTRING 
--to=git@vger.kernel.org --cc=MAINTAINER --smtp-debug=1 NAME.patch
+
 
 Know the status of your patch after submission
 
-- 
1.9.1

Re: minor typos in documentation

[René Genz]

Hi Stefan,

I submitted the patch to the mailing list.
Based on my experience I submitted another patch to improve the documentation.

Thank you for guiding me.
--
Kind regards,
René

[PATCH] doc: git-pull.txt use US spelling, fix minor typo

[René Genz]

---
Instead of using two command lines I could have replaced the comma with a 
semicolon.

I do not mind, if this patch is squashed into the other minor typo fixes of 
mine:
3c228f462d02e76956062b8d8572158cbcdbbc7b


 Documentation/git-pull.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 4470e4b..942af8e 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -67,7 +67,7 @@ with uncommitted changes is discouraged: while possible, it 
leaves you
 in a state that may be hard to back out of in the case of a conflict.
 
 If any of the remote changes overlap with local uncommitted changes,
-the merge will be automatically cancelled and the work tree untouched.
+the merge will be automatically canceled and the work tree untouched.
 It is generally best to get any local changes in working order before
 pulling or stash them away with linkgit:git-stash[1].
 
@@ -210,7 +210,8 @@ EXAMPLES
   current branch:
 +
 
-$ git pull, git pull origin
+$ git pull
+$ git pull origin
 
 +
 Normally the branch merged in is the HEAD of the remote repository,
-- 
1.9.1

[PATCH v2] doc: git-pull.txt use US spelling, fix minor typo

[René Genz]

Signed-off-by: René Genz <liebundar...@freenet.de>
---
 Documentation/git-pull.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 4470e4b..942af8e 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -67,7 +67,7 @@ with uncommitted changes is discouraged: while possible, it 
leaves you
 in a state that may be hard to back out of in the case of a conflict.
 
 If any of the remote changes overlap with local uncommitted changes,
-the merge will be automatically cancelled and the work tree untouched.
+the merge will be automatically canceled and the work tree untouched.
 It is generally best to get any local changes in working order before
 pulling or stash them away with linkgit:git-stash[1].
 
@@ -210,7 +210,8 @@ EXAMPLES
   current branch:
 +
 
-$ git pull, git pull origin
+$ git pull
+$ git pull origin
 
 +
 Normally the branch merged in is the HEAD of the remote repository,
-- 
1.9.1

[PATCH v2] fix minor typing mistakes

[René Genz]

Helped-by: Stefan Beller <sbel...@google.com>
Signed-off-by: René Genz <liebundar...@freenet.de>
---
 Documentation/git-commit.txt| 4 ++--
 Documentation/gitremote-helpers.txt | 2 +-
 ci/run-windows-build.sh | 2 +-
 diff.c  | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index ed0f5b9..afb06ad 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -95,7 +95,7 @@ OPTIONS
 
 --reset-author::
When used with -C/-c/--amend options, or when committing after a
-   a conflicting cherry-pick, declare that the authorship of the
+   conflicting cherry-pick, declare that the authorship of the
resulting commit now belongs to the committer. This also renews
the author timestamp.
 
@@ -112,7 +112,7 @@ OPTIONS
`--dry-run`.
 
 --long::
-   When doing a dry-run, give the output in a the long-format.
+   When doing a dry-run, give the output in the long-format.
Implies `--dry-run`.
 
 -z::
diff --git a/Documentation/gitremote-helpers.txt 
b/Documentation/gitremote-helpers.txt
index e4b785e..4a584f3 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -463,7 +463,7 @@ set by Git if the remote helper has the 'option' capability.
GPG sign pushes.
 
 'option push-option ::
-   Transmit  as a push option. As the a push option
+   Transmit  as a push option. As the push option
must not contain LF or NUL characters, the string is not encoded.
 
 SEE ALSO
diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh
index 4e3a50b..9f89d54 100755
--- a/ci/run-windows-build.sh
+++ b/ci/run-windows-build.sh
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# Script to trigger the a Git for Windows build and test run.
+# Script to trigger the Git for Windows build and test run.
 # Set the $GFW_CI_TOKEN as environment variable.
 # Pass the branch (only branches on https://github.com/git/git are
 # supported) and a commit hash.
diff --git a/diff.c b/diff.c
index 11eef1c..74283d9 100644
--- a/diff.c
+++ b/diff.c
@@ -911,7 +911,7 @@ static int fn_out_diff_words_write_helper(FILE *fp,
 /*
  * '--color-words' algorithm can be described as:
  *
- *   1. collect a the minus/plus lines of a diff hunk, divided into
+ *   1. collect the minus/plus lines of a diff hunk, divided into
  *  minus-lines and plus-lines;
  *
  *   2. break both minus-lines and plus-lines into words and
-- 
1.9.1

[PATCH] doc: update SubmittingPatches

[René Genz]

-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>
---
 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
 
-- 
1.9.1