doc: fix repeated words

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>
This commit is contained in:
Mark Rushakoff 2019-08-09 22:59:14 -07:00 committed by Junio C Hamano
parent 2e27de94d4
commit 24966cd982
9 changed files with 9 additions and 9 deletions

View 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.

View 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.

View 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

View 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.

View 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.

View 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.
+
--

View 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.

View 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.

View 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).