[1/1] doc: fix repeated words

Commit Message

Linus Arver via GitGitGadget Aug. 10, 2019, 5:59 a.m. UTC

From: Mark Rushakoff <[e-mail]>

Inspired by 21416f0a07 ("restore: fix typo in docs", 2019-08-03), I ran
"git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases
where words were duplicated, e.g. "the the", and in most cases removed
one of the repeated words.

There were many false positives by this grep command, including
deliberate repeated words like "really really" or valid uses of "that
that" which I left alone, of course.

I also did not correct any of the legitimate, accidentally repeated
words in old RelNotes.

Signed-off-by: Mark Rushakoff <[e-mail]>
---
 Documentation/config/color.txt                       | 2 +-
 Documentation/config/stash.txt                       | 2 +-
 Documentation/git-fast-export.txt                    | 2 +-
 Documentation/git-fast-import.txt                    | 2 +-
 Documentation/git-pack-objects.txt                   | 2 +-
 Documentation/git-push.txt                           | 2 +-
 Documentation/git-repack.txt                         | 2 +-
 Documentation/technical/hash-function-transition.txt | 2 +-
 Documentation/technical/protocol-v2.txt              | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

Comments

Jeff King Aug. 10, 2019, 6:03 a.m. UTC | #1

On Fri, Aug 09, 2019 at 10:59:14PM -0700, Mark Rushakoff via GitGitGadget wrote:

> From: Mark Rushakoff <[e-mail]>
> 
> Inspired by 21416f0a07 ("restore: fix typo in docs", 2019-08-03), I ran
> "git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases
> where words were duplicated, e.g. "the the", and in most cases removed
> one of the repeated words.
> 
> There were many false positives by this grep command, including
> deliberate repeated words like "really really" or valid uses of "that
> that" which I left alone, of course.
> 
> I also did not correct any of the legitimate, accidentally repeated
> words in old RelNotes.

Thanks. I read over each of these, and they are all obviously the right
thing to do.

-Peff

Junio C Hamano Aug. 12, 2019, 12:40 a.m. UTC | #2

Jeff King <[e-mail]> writes:

>> There were many false positives by this grep command, including
>> deliberate repeated words like "really really" or valid uses of "that
>> that" which I left alone, of course.
>> 
>> I also did not correct any of the legitimate, accidentally repeated
>> words in old RelNotes.
>
> Thanks. I read over each of these, and they are all obviously the right
> thing to do.

Thanks, both.

Patch

diff --git a/Documentation/config/color.txt b/Documentation/config/color.txt
index 8375596c44..d5daacb13a 100644
--- a/Documentation/config/color.txt
+++ b/Documentation/config/color.txt
@@ -14,7 +14,7 @@  color.blame.highlightRecent::
 +
 This setting should be set to a comma-separated list of color and date settings,
 starting and ending with a color, the dates should be set from oldest to newest.
-The metadata will be colored given the colors if the the line was introduced
+The metadata will be colored given the colors if the line was introduced
 before the given timestamp, overwriting older timestamped colors.
 +
 Instead of an absolute timestamp relative timestamps work as well, e.g.
diff --git a/Documentation/config/stash.txt b/Documentation/config/stash.txt
index 7710758efb..abc7ef4a3a 100644
--- a/Documentation/config/stash.txt
+++ b/Documentation/config/stash.txt
@@ -4,7 +4,7 @@  stash.useBuiltin::
        the built-in rewrite of it in C.
 +
 The C rewrite is first included with Git version 2.22 (and Git for Windows
-version 2.19). This option serves an an escape hatch to re-enable the
+version 2.19). This option serves as an escape hatch to re-enable the
 legacy version in case any bugs are found in the rewrite. This option and
 the shell script version of linkgit:git-stash[1] will be removed in some
 future release.
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 11427acdde..cc940eb9ad 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -116,7 +116,7 @@  marks the same across runs.
 	and will make master{tilde}4 no longer have master{tilde}5 as
 	a parent (though both the old master{tilde}4 and new
 	master{tilde}4 will have all the same files).  Use
-	--reference-excluded-parents to instead have the the stream
+	--reference-excluded-parents to instead have the stream
 	refer to commits in the excluded range of history by their
 	sha1sum.  Note that the resulting stream can only be used by a
 	repository which already contains the necessary parent
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 7baf9e47b5..fad327aecc 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -425,7 +425,7 @@  the same commit, as `filedeleteall` wipes the branch clean (see below).
 
 The `LF` after the command is optional (it used to be required).  Note
 that for reasons of backward compatibility, if the commit ends with a
-`data` command (i.e. it has has no `from`, `merge`, `filemodify`,
+`data` command (i.e. it has no `from`, `merge`, `filemodify`,
 `filedelete`, `filecopy`, `filerename`, `filedeleteall` or
 `notemodify` commands) then two `LF` commands may appear at the end of
 the command instead of just one.
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index e45f3e680d..fecdf2600c 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -131,7 +131,7 @@  depth is 4095.
 --keep-pack=<pack-name>::
 	This flag causes an object already in the given pack to be
 	ignored, even if it would have otherwise been
-	packed. `<pack-name>` is the the pack file name without
+	packed. `<pack-name>` is the pack file name without
 	leading directory (e.g. `pack-123.pack`). The option could be
 	specified multiple times to keep multiple packs.
 
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6a8a0d958b..3b8053447e 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -75,7 +75,7 @@  without any `<refspec>` on the command line.  Otherwise, missing
 +
 If <dst> doesn't start with `refs/` (e.g. `refs/heads/master`) we will
 try to infer where in `refs/*` on the destination <repository> it
-belongs based on the the type of <src> being pushed and whether <dst>
+belongs based on the type of <src> being pushed and whether <dst>
 is ambiguous.
 +
 --
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index aa0cc8bd44..92f146d27d 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -142,7 +142,7 @@  depth is 4095.
 
 --keep-pack=<pack-name>::
 	Exclude the given pack from repacking. This is the equivalent
-	of having `.keep` file on the pack. `<pack-name>` is the the
+	of having `.keep` file on the pack. `<pack-name>` is the
 	pack file name without leading directory (e.g. `pack-123.pack`).
 	The option could be specified multiple times to keep multiple
 	packs.
diff --git a/Documentation/technical/hash-function-transition.txt b/Documentation/technical/hash-function-transition.txt
index bc2ace2a6e..2ae8fa470a 100644
--- a/Documentation/technical/hash-function-transition.txt
+++ b/Documentation/technical/hash-function-transition.txt
@@ -456,7 +456,7 @@  packfile marked as UNREACHABLE_GARBAGE (using the PSRC field; see
 below). To avoid the race when writing new objects referring to an
 about-to-be-deleted object, code paths that write new objects will
 need to copy any objects from UNREACHABLE_GARBAGE packs that they
-refer to to new, non-UNREACHABLE_GARBAGE packs (or loose objects).
+refer to new, non-UNREACHABLE_GARBAGE packs (or loose objects).
 UNREACHABLE_GARBAGE are then safe to delete if their creation time (as
 indicated by the file's mtime) is long enough ago.
 
diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt
index 03264c7d9a..40f91f6b1e 100644
--- a/Documentation/technical/protocol-v2.txt
+++ b/Documentation/technical/protocol-v2.txt
@@ -141,7 +141,7 @@  Capabilities
 ------------
 
 There are two different types of capabilities: normal capabilities,
-which can be used to to convey information or alter the behavior of a
+which can be used to convey information or alter the behavior of a
 request, and commands, which are the core actions that a client wants to
 perform (fetch, push, etc).