Documentation: clean up various typos in technical docs
Used GNU "aspell check <filename>" to review various technical documentation files with the default aspell dictionary. Ignored false-positives between american and british english. Signed-off-by: Jacob Stopak <jacob@initialcommit.io> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jacob Stopak committed
Sep 19, 2022 at 19:45 UTC
bbb0c357b81d86dfd0b843cabe6c8fe29ced9ebd
4 files changed
+7
-7
Documentation/technical/api-parse-options.txt
+1
-1
@@ -60,7 +60,7 @@ Subcommands are special in a couple of ways:
60
61
* All arguments following the subcommand are considered to be arguments of
62
the subcommand, and, conversely, arguments meant for the subcommand may
63
- not preceed the subcommand.
63
+ not precede the subcommand.
64
65
Therefore, if the options array contains at least one subcommand and
66
`parse_options()` encounters the first dashless argument, it will either:
Documentation/technical/bundle-uri.txt
+3
-3
@@ -290,7 +290,7 @@ expect that the process will end when all prerequisite commit OIDs in a
290
thin bundle are already in the object database.
291
292
When using the `creationToken` heuristic, the client can avoid downloading
293
-any bundles if their creation tokenss are not larger than the stored
293
+any bundles if their creation tokens are not larger than the stored
294
creation token. After fetching new bundles, Git updates this local
295
creation token.
296
@@ -319,7 +319,7 @@ Here are a few example error conditions:
319
Git's other HTTP protocols in terms of handling specific 400-level
320
errors.
321
322
-* The server reports any other failure reponse.
322
+* The server reports any other failure response.
323
324
* The client receives data that is not parsable as a bundle or bundle list.
325
@@ -447,7 +447,7 @@ created every hour, and then once a day those "hourly" bundles could be
447
merged into a "daily" bundle. The daily bundles are merged into the
448
oldest bundle after 30 days.
449
450
-It is recommened that this bundle strategy is repeated with the `blob:none`
450
+It is recommended that this bundle strategy is repeated with the `blob:none`
451
filter if clients of this repository are expecting to use blobless partial
452
clones. This list of blobless bundles stays in the same list as the full
453
bundles, but uses the `bundle.<id>.filter` key to separate the two groups.
Documentation/technical/commit-graph.txt
+2
-2
@@ -40,7 +40,7 @@ Values 1-4 satisfy the requirements of parse_commit_gently().
40
41
There are two definitions of generation number:
42
1. Corrected committer dates (generation number v2)
43
-2. Topological levels (generation nummber v1)
43
+2. Topological levels (generation number v1)
44
45
Define "corrected committer date" of a commit recursively as follows:
46
@@ -48,7 +48,7 @@ Define "corrected committer date" of a commit recursively as follows:
48
equal to its committer date.
49
50
* A commit with at least one parent has corrected committer date equal to
51
- the maximum of its commiter date and one more than the largest corrected
51
+ the maximum of its committer date and one more than the largest corrected
52
committer date among its parents.
53
54
* As a special case, a root commit with timestamp zero has corrected commit
Documentation/technical/remembering-renames.txt
+1
-1
@@ -407,7 +407,7 @@ considered to be "irrelevant". See for example the following commits:
407
no longer relevant", 2021-03-13)
408
409
Relevance is always determined by what the _other_ side of history has
410
-done, in terms of modifing a file that our side renamed, or adding a
410
+done, in terms of modifying a file that our side renamed, or adding a
411
file to a directory which our side renamed. This means that a path
412
that is "irrelevant" when picking the first commit of a series in a
413
rebase or cherry-pick, may suddenly become "relevant" when picking the