doc: fix repeated words
authorMark Rushakoff <mark.rushakoff@gmail.com>
Sat, 10 Aug 2019 05:59:14 +0000 (22:59 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 12 Aug 2019 00:40:07 +0000 (17:40 -0700)
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 <mark.rushakoff@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/config/color.txt
Documentation/config/stash.txt
Documentation/git-fast-export.txt
Documentation/git-fast-import.txt
Documentation/git-pack-objects.txt
Documentation/git-push.txt
Documentation/git-repack.txt
Documentation/technical/hash-function-transition.txt
Documentation/technical/protocol-v2.txt
index 8375596c4420ddb5fcc52fea6da0288d1330b8dc..d5daacb13a2c77160accac4e46b1381cf8214f24 100644 (file)
@@ -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.
index 7710758efb5340c15e4df93d9669800bfb5cec16..abc7ef4a3a5c64f634dbe0a95bbef01d65151321 100644 (file)
@@ -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.
index 11427acdde68e659ca5d443beff037df8c9f3ebb..cc940eb9ada3ce65bd3e57af73da59b77c99acbc 100644 (file)
@@ -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
index 7baf9e47b5e61391fbfd5fe44acbfa9943bbe397..fad327aecc1b91c0ed48df740c25fd444eb1431b 100644 (file)
@@ -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.
index e45f3e680d3632c8122db01b2a51cc3971c27922..fecdf2600cc9e2c5fe7535231deaab79fc0a7278 100644 (file)
@@ -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.
 
index 6a8a0d958bc63db19bfa4786e85e9e14061f1661..3b8053447e204499f28ab1616ce74efa87524536 100644 (file)
@@ -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.
 +
 --
index aa0cc8bd445c99703d6ee17346d656104194dda8..92f146d27dc363519e04d0b132e43b0a4667cac8 100644 (file)
@@ -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.
index bc2ace2a6e0563f655fedb5681307b43c98cedc7..2ae8fa470ada107bd26302543ac93197e0e00c2e 100644 (file)
@@ -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.
 
index 03264c7d9a833bc4ed8d15be262bf6186a67c892..40f91f6b1ee1efcf87c2e694b298d1da68901b8a 100644 (file)
@@ -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).