@@ -60,7 +60,7 @@ Subcommands are special in a couple of ways:
* All arguments following the subcommand are considered to be arguments of
the subcommand, and, conversely, arguments meant for the subcommand may
- not preceed the subcommand.
+ not precede the subcommand.
Therefore, if the options array contains at least one subcommand and
`parse_options()` encounters the first dashless argument, it will either:
@@ -290,7 +290,7 @@ expect that the process will end when all prerequisite commit OIDs in a
thin bundle are already in the object database.
When using the `creationToken` heuristic, the client can avoid downloading
-any bundles if their creation tokenss are not larger than the stored
+any bundles if their creation tokens are not larger than the stored
creation token. After fetching new bundles, Git updates this local
creation token.
@@ -319,7 +319,7 @@ Here are a few example error conditions:
Git's other HTTP protocols in terms of handling specific 400-level
errors.
-* The server reports any other failure reponse.
+* The server reports any other failure response.
* The client receives data that is not parsable as a bundle or bundle list.
@@ -447,7 +447,7 @@ created every hour, and then once a day those "hourly" bundles could be
merged into a "daily" bundle. The daily bundles are merged into the
oldest bundle after 30 days.
-It is recommened that this bundle strategy is repeated with the `blob:none`
+It is recommended that this bundle strategy is repeated with the `blob:none`
filter if clients of this repository are expecting to use blobless partial
clones. This list of blobless bundles stays in the same list as the full
bundles, but uses the `bundle.<id>.filter` key to separate the two groups.
@@ -40,7 +40,7 @@ Values 1-4 satisfy the requirements of parse_commit_gently().
There are two definitions of generation number:
1. Corrected committer dates (generation number v2)
-2. Topological levels (generation nummber v1)
+2. Topological levels (generation number v1)
Define "corrected committer date" of a commit recursively as follows:
@@ -48,7 +48,7 @@ Define "corrected committer date" of a commit recursively as follows:
equal to its committer date.
* A commit with at least one parent has corrected committer date equal to
- the maximum of its commiter date and one more than the largest corrected
+ the maximum of its committer date and one more than the largest corrected
committer date among its parents.
* As a special case, a root commit with timestamp zero has corrected commit
@@ -407,7 +407,7 @@ considered to be "irrelevant". See for example the following commits:
no longer relevant", 2021-03-13)
Relevance is always determined by what the _other_ side of history has
-done, in terms of modifing a file that our side renamed, or adding a
+done, in terms of modifying a file that our side renamed, or adding a
file to a directory which our side renamed. This means that a path
that is "irrelevant" when picking the first commit of a series in a
rebase or cherry-pick, may suddenly become "relevant" when picking the
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> --- Documentation/technical/api-parse-options.txt | 2 +- Documentation/technical/bundle-uri.txt | 6 +++--- Documentation/technical/commit-graph.txt | 4 ++-- Documentation/technical/remembering-renames.txt | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-)