Merge branch 'en/doc-typofix'

Docfix.

* en/doc-typofix:
  Fix spelling errors in no-longer-updated-from-upstream modules
  multimail: fix a few simple spelling errors
  sha1dc: fix trivial comment spelling error
  Fix spelling errors in test commands
  Fix spelling errors in messages shown to users
  Fix spelling errors in names of tests
  Fix spelling errors in comments of testcases
  Fix spelling errors in code comments
  Fix spelling errors in documentation outside of Documentation/
  Documentation: fix a bunch of typos, both old and new
This commit is contained in:
Junio C Hamano
2019-12-01 09:04:35 -08:00
141 changed files with 214 additions and 214 deletions

View File

@ -58,7 +58,7 @@ Functions
Whenever a submodule configuration is parsed in `parse_submodule_config_option`
via e.g. `gitmodules_config()`, it will overwrite the null_sha1 entry.
So in the normal case, when HEAD:.gitmodules is parsed first and then overlayed
So in the normal case, when HEAD:.gitmodules is parsed first and then overlaid
with the repository configuration, the null_sha1 entry contains the local
configuration of a submodule (e.g. consolidated values from local git
configuration and the .gitmodules file in the worktree).

View File

@ -178,7 +178,7 @@ describe the simplified forms.
== Public API
All Trace2 API functions send a messsage to all of the active
All Trace2 API functions send a message to all of the active
Trace2 Targets. This section describes the set of available
messages.
@ -377,7 +377,7 @@ of `pthread_create()`.
and the thread elapsed time.
+
This function must be called by the thread-proc before it returns
(so that the coorect TLS data is used and cleaned up. It should
(so that the correct TLS data is used and cleaned up). It should
not be called by the caller of `pthread_join()`.
=== Region and Data Messages
@ -406,7 +406,7 @@ The `label` field is an arbitrary label used to describe the activity
being started, such as "read_recursive" or "do_read_index".
+
The `repo` field, if set, will be used to get the "repo-id", so that
recursive oerations can be attributed to the correct repository.
recursive operations can be attributed to the correct repository.
`void trace2_region_leave(const char *category, const char *label, const struct repository *repo)`::
@ -421,7 +421,7 @@ This function pops the region nesting stack on the current thread
and reports the elapsed time of the stack frame.
+
The `category`, `label`, and `repo` fields are the same as above.
The `category` and `label` do not need to match the correpsonding
The `category` and `label` do not need to match the corresponding
"region_enter" message, but it makes the data stream easier to
understand.
@ -816,7 +816,7 @@ with "?".
Note that the session-id of the child process is not available to
the current/spawning process, so the child's PID is reported here as
a hint for post-processing. (But it is only a hint because the child
proces may be a shell script which doesn't have a session-id.)
process may be a shell script which doesn't have a session-id.)
+
Note that the `t_rel` field contains the observed run time in seconds
for the child process (starting before the fork/exec/spawn and
@ -1176,7 +1176,7 @@ d0 | main | atexit | | 0.028809 | |
+
Regions may be nested. This causes messages to be indented in the
PERF target, for example.
Elapsed times are relative to the start of the correpsonding nesting
Elapsed times are relative to the start of the corresponding nesting
level as expected. For example, if we add region message to:
+
----------------
@ -1371,7 +1371,7 @@ d0 | main | atexit | | 0.030027 | |
In this example, the preload region took 0.009122 seconds. The 7 threads
took between 0.006069 and 0.008947 seconds to work on their portion of
the index. Thread "th01" worked on 508 items at offset 0. Thread "th02"
worked on 508 items at offset 2032. Thread "th04" worked on 508 itemts
worked on 508 items at offset 2032. Thread "th04" worked on 508 items
at offset 508.
+
This example also shows that thread names are assigned in a racy manner

View File

@ -22,11 +22,11 @@ as "commit-graph" either in the .git/objects/info directory or in the info
directory of an alternate.
The commit-graph file stores the commit graph structure along with some
extra metadata to speed up graph walks. By listing commit OIDs in lexi-
cographic order, we can identify an integer position for each commit and
refer to the parents of a commit using those integer positions. We use
binary search to find initial commits and then use the integer positions
for fast lookups during the walk.
extra metadata to speed up graph walks. By listing commit OIDs in
lexicographic order, we can identify an integer position for each commit
and refer to the parents of a commit using those integer positions. We
use binary search to find initial commits and then use the integer
positions for fast lookups during the walk.
A consumer may load the following info for a commit from the graph:
@ -85,7 +85,7 @@ have generation number represented by the macro GENERATION_NUMBER_ZERO = 0.
Since the commit-graph file is closed under reachability, we can guarantee
the following weaker condition on all commits:
If A and B are commits with generation numbers N amd M, respectively,
If A and B are commits with generation numbers N and M, respectively,
and N < M, then A cannot reach B.
Note how the strict inequality differs from the inequality when we have

View File

@ -531,7 +531,7 @@ Until Git protocol gains SHA-256 support, using SHA-256 based storage
on public-facing Git servers is strongly discouraged. Once Git
protocol gains SHA-256 support, SHA-256 based servers are likely not
to support SHA-1 compatibility, to avoid what may be a very expensive
hash reencode during clone and to encourage peers to modernize.
hash re-encode during clone and to encourage peers to modernize.
The design described here allows fetches by SHA-1 clients of a
personal SHA-256 repository because it's not much more difficult than
@ -602,7 +602,7 @@ git --output-format=sha1 log abac87a^{sha1}..f787cac^{sha256}
Choice of Hash
--------------
In early 2005, around the time that Git was written, Xiaoyun Wang,
In early 2005, around the time that Git was written, Xiaoyun Wang,
Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1
collisions in 2^69 operations. In August they published details.
Luckily, no practical demonstrations of a collision in full SHA-1 were

View File

@ -318,7 +318,7 @@ The remaining data of each directory block is grouped by type:
== End of Index Entry
The End of Index Entry (EOIE) is used to locate the end of the variable
length index entries and the begining of the extensions. Code can take
length index entries and the beginning of the extensions. Code can take
advantage of this to quickly locate the index extensions without having
to parse through all of the index entries.
@ -351,7 +351,7 @@ The remaining data of each directory block is grouped by type:
- A number of index offset entries each consisting of:
- 32-bit offset from the begining of the file to the first cache entry
- 32-bit offset from the beginning of the file to the first cache entry
in this block of entries.
- 32-bit count of cache entries in this block

View File

@ -644,7 +644,7 @@ update was successful, or 'ng [refname] [error]' if the update was not.
command-ok = PKT-LINE("ok" SP refname)
command-fail = PKT-LINE("ng" SP refname SP error-msg)
error-msg = 1*(OCTECT) ; where not "ok"
error-msg = 1*(OCTET) ; where not "ok"
----
Updates can be unsuccessful for a number of reasons. The reference can have

View File

@ -32,7 +32,7 @@ if/when needed.
A remote that can later provide the missing objects is called a
promisor remote, as it promises to send the objects when
requested. Initialy Git supported only one promisor remote, the origin
requested. Initially Git supported only one promisor remote, the origin
remote from which the user cloned and that was configured in the
"extensions.partialClone" config option. Later support for more than
one promisor remote has been implemented.

View File

@ -252,7 +252,7 @@ A `fetch` request can take the following arguments:
ofs-delta
Indicate that the client understands PACKv2 with delta referring
to its base by position in pack rather than by an oid. That is,
they can read OBJ_OFS_DELTA (ake type 6) in a packfile.
they can read OBJ_OFS_DELTA (aka type 6) in a packfile.
If the 'shallow' feature is advertised the following arguments can be
included in the clients request as well as the potential addition of the

View File

@ -117,7 +117,7 @@ early A became C or B, a late X became Y or Z". We can see there are
4 combinations of ("B or C", "C or B") x ("X or Y", "Y or X").
By sorting, the conflict is given its canonical name, namely, "an
early part became B or C, a late part becames X or Y", and whenever
early part became B or C, a late part became X or Y", and whenever
any of these four patterns appear, and we can get to the same conflict
and resolution that we saw earlier.