зеркало из https://github.com/microsoft/git.git
documentation: fix typos
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Родитель
82e81edf71
Коммит
384f7d17d2
|
@ -174,7 +174,7 @@
|
|||
(FATAL) Missing end-of-line in the object header.
|
||||
|
||||
`zeroPaddedDate`::
|
||||
(ERROR) Found a zero padded date in an author/commiter line.
|
||||
(ERROR) Found a zero padded date in an author/committer line.
|
||||
|
||||
`zeroPaddedFilemode`::
|
||||
(WARN) Found a zero padded filemode in a tree.
|
||||
|
|
|
@ -20,7 +20,7 @@ and extract the commit ID stored in it. It reads only the first
|
|||
1024 bytes of input, thus its runtime is not influenced by the size
|
||||
of the tar archive very much.
|
||||
|
||||
If no commit ID is found, 'git get-tar-commit-id' quietly exists with a
|
||||
If no commit ID is found, 'git get-tar-commit-id' quietly exits with a
|
||||
return code of 1. This can happen if the archive had not been created
|
||||
using 'git archive' or if the first parameter of 'git archive' had been
|
||||
a tree ID instead of a commit ID or tag.
|
||||
|
|
|
@ -337,7 +337,7 @@ The `--threads` option (and the grep.threads configuration) will be ignored when
|
|||
|
||||
When grepping the object store (with `--cached` or giving tree objects), running
|
||||
with multiple threads might perform slower than single threaded if `--textconv`
|
||||
is given and there're too many text conversions. So if you experience low
|
||||
is given and there are too many text conversions. So if you experience low
|
||||
performance in this case, it might be desirable to use `--threads=1`.
|
||||
|
||||
CONFIGURATION
|
||||
|
|
|
@ -26,7 +26,7 @@ OPTIONS
|
|||
-------
|
||||
|
||||
--[no-]strict::
|
||||
Do not try <directory>/.git/ if <directory> is no Git directory.
|
||||
Do not try <directory>/.git/ if <directory> is not a Git directory.
|
||||
|
||||
--timeout=<n>::
|
||||
Interrupt transfer after <n> seconds of inactivity.
|
||||
|
|
|
@ -42,7 +42,7 @@ Each row consists of a 4-byte chunk identifier (ID) and an 8-byte offset.
|
|||
Each integer is stored in network-byte order.
|
||||
|
||||
The chunk identifier `ID[i]` is a label for the data stored within this
|
||||
fill from `OFFSET[i]` (inclusive) to `OFFSET[i+1]` (exclusive). Thus, the
|
||||
file from `OFFSET[i]` (inclusive) to `OFFSET[i+1]` (exclusive). Thus, the
|
||||
size of the `i`th chunk is equal to the difference between `OFFSET[i+1]`
|
||||
and `OFFSET[i]`. This requires that the chunk data appears contiguously
|
||||
in the same order as the table of contents.
|
||||
|
|
|
@ -17,8 +17,8 @@ $GIT_DIR/objects/pack/multi-pack-index
|
|||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
The Git pack format is now Git stores most of its primary repository
|
||||
data. Over the lietime af a repository loose objects (if any) and
|
||||
The Git pack format is how Git stores most of its primary repository
|
||||
data. Over the lifetime of a repository loose objects (if any) and
|
||||
smaller packs are consolidated into larger pack(s). See
|
||||
linkgit:git-gc[1] and linkgit:git-pack-objects[1].
|
||||
|
||||
|
|
|
@ -273,7 +273,7 @@ request include-tag only has to do with the client's desires for tag
|
|||
data, whether or not a server had advertised objects in the
|
||||
refs/tags/* namespace.
|
||||
|
||||
Servers MUST pack the tags if their referrant is packed and the client
|
||||
Servers MUST pack the tags if their referent is packed and the client
|
||||
has requested include-tags.
|
||||
|
||||
Clients MUST be prepared for the case where a server has ignored
|
||||
|
|
|
@ -136,7 +136,7 @@ Design Details
|
|||
|
||||
- Commit grafts and replace objects can change the shape of the commit
|
||||
history. The latter can also be enabled/disabled on the fly using
|
||||
`--no-replace-objects`. This leads to difficultly storing both possible
|
||||
`--no-replace-objects`. This leads to difficulty storing both possible
|
||||
interpretations of a commit id, especially when computing generation
|
||||
numbers. The commit-graph will not be read or written when
|
||||
replace-objects or grafts are present.
|
||||
|
|
|
@ -148,7 +148,7 @@ information, the main process handles the results in two steps:
|
|||
|
||||
- First, it updates the in-memory index with the `lstat()` information
|
||||
sent by the workers. (This must be done first as this information
|
||||
might me required in the following step.)
|
||||
might be required in the following step.)
|
||||
|
||||
- Then it writes the items which collided on disk (i.e. items marked
|
||||
with `PC_ITEM_COLLIDED`). More on this below.
|
||||
|
@ -232,7 +232,7 @@ conversion and re-encoding, are eligible for parallel checkout.
|
|||
Ineligible entries are checked out by the classic sequential codepath
|
||||
*before* spawning workers.
|
||||
|
||||
Note: submodules's files are also eligible for parallel checkout (as
|
||||
Note: submodules' files are also eligible for parallel checkout (as
|
||||
long as they don't fall into any of the excluding categories mentioned
|
||||
above). But since each submodule is checked out in its own child
|
||||
process, we don't mix the superproject's and the submodules' files in
|
||||
|
|
Загрузка…
Ссылка в новой задаче