Merge branch 'js/typofix'
* js/typofix: Documentation: clean up various typos in technical docs Documentation: clean up a few misspelled word typos
This commit is contained in:
commit
4140830d25
@ -1160,7 +1160,7 @@ all named like `v2-000n-my-commit-subject.patch`. `-v2` will also format
|
||||
your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]",
|
||||
and your range-diff will be prefaced with "Range-diff against v1".
|
||||
|
||||
Afer you run this command, `format-patch` will output the patches to the `psuh/`
|
||||
After you run this command, `format-patch` will output the patches to the `psuh/`
|
||||
directory, alongside the v1 patches. Using a single directory makes it easy to
|
||||
refer to the old v1 patches while proofreading the v2 patches, but you will need
|
||||
to be careful to send out only the v2 patches. We will use a pattern like
|
||||
|
@ -534,7 +534,7 @@ the arguments to `traverse_commit_list()`.
|
||||
- `void *show_data`: A context buffer which is passed in turn to `show_commit`
|
||||
and `show_object`.
|
||||
|
||||
In addition, `traverse_commit_list_filtered()` has an additional paramter:
|
||||
In addition, `traverse_commit_list_filtered()` has an additional parameter:
|
||||
|
||||
- `struct oidset *omitted`: A linked-list of object IDs which the provided
|
||||
filter caused to be omitted.
|
||||
|
@ -344,7 +344,7 @@ Repository, command and file interfaces
|
||||
|
||||
This documentation discusses repository and command interfaces which
|
||||
users are expected to interact with directly. See `--user-formats` in
|
||||
linkgit:git-help[1] for more details on the critera.
|
||||
linkgit:git-help[1] for more details on the criteria.
|
||||
|
||||
include::cmds-userinterfaces.txt[]
|
||||
|
||||
|
@ -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:
|
||||
|
@ -289,7 +289,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.
|
||||
|
||||
@ -318,7 +318,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.
|
||||
|
||||
@ -446,7 +446,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
|
||||
|
Loading…
Reference in New Issue
Block a user