зеркало из https://github.com/microsoft/git.git
Documentation: typofixes
In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Родитель
dd83521629
Коммит
f745acb028
|
@ -85,7 +85,7 @@ UI, Workflows & Features
|
|||
public repository really point the commits the pusher wanted to,
|
||||
without having to "trust" the server.
|
||||
|
||||
* "git interpret-trailers" is a new filter to programatically edit
|
||||
* "git interpret-trailers" is a new filter to programmatically edit
|
||||
the tail end of the commit log messages.
|
||||
|
||||
* "git help everyday" shows the "Everyday Git in 20 commands or so"
|
||||
|
|
|
@ -1210,7 +1210,7 @@ gc.autopacklimit::
|
|||
default value is 50. Setting this to 0 disables it.
|
||||
|
||||
gc.autodetach::
|
||||
Make `git gc --auto` return immediately andrun in background
|
||||
Make `git gc --auto` return immediately and run in background
|
||||
if the system supports it. Default is true.
|
||||
|
||||
gc.packrefs::
|
||||
|
@ -1357,7 +1357,7 @@ gpg.program::
|
|||
same command-line interface as GPG, namely, to verify a detached
|
||||
signature, "gpg --verify $file - <$signature" is run, and the
|
||||
program is expected to signal a good signature by exiting with
|
||||
code 0, and to generate an ascii-armored detached signature, the
|
||||
code 0, and to generate an ASCII-armored detached signature, the
|
||||
standard input of "gpg -bsau $key" is fed with the contents to be
|
||||
signed, and the program is expected to send the result to its
|
||||
standard output.
|
||||
|
@ -1592,7 +1592,7 @@ http.useragent::
|
|||
Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
|
||||
|
||||
http.<url>.*::
|
||||
Any of the http.* options above can be applied selectively to some urls.
|
||||
Any of the http.* options above can be applied selectively to some URLs.
|
||||
For a config key to match a URL, each element of the config key is
|
||||
compared to that of the URL, in the following order:
|
||||
+
|
||||
|
@ -1631,8 +1631,8 @@ if the URL is `https://user@example.com/foo/bar` a config key match of
|
|||
+
|
||||
All URLs are normalized before attempting any matching (the password part,
|
||||
if embedded in the URL, is always ignored for matching purposes) so that
|
||||
equivalent urls that are simply spelled differently will match properly.
|
||||
Environment variable settings always override any matches. The urls that are
|
||||
equivalent URLs that are simply spelled differently will match properly.
|
||||
Environment variable settings always override any matches. The URLs that are
|
||||
matched against are those given directly to Git commands. This means any URLs
|
||||
visited as a result of a redirection do not participate in matching.
|
||||
|
||||
|
|
|
@ -119,7 +119,7 @@ developed and maintained during years or even tens of years by a lot
|
|||
of people. And as there are often many people who depend (sometimes
|
||||
critically) on such software, regressions are a really big problem.
|
||||
|
||||
One such software is the linux kernel. And if we look at the linux
|
||||
One such software is the Linux kernel. And if we look at the Linux
|
||||
kernel, we can see that a lot of time and effort is spent to fight
|
||||
regressions. The release cycle start with a 2 weeks long merge
|
||||
window. Then the first release candidate (rc) version is tagged. And
|
||||
|
@ -132,7 +132,7 @@ regressions. And this time is more than 80% of the release cycle
|
|||
time. But this is not the end of the fight yet, as of course it
|
||||
continues after the release.
|
||||
|
||||
And then this is what Ingo Molnar (a well known linux kernel
|
||||
And then this is what Ingo Molnar (a well known Linux kernel
|
||||
developer) says about his use of git bisect:
|
||||
|
||||
_____________
|
||||
|
|
|
@ -98,7 +98,7 @@ clean::
|
|||
filter by pattern::
|
||||
|
||||
This shows the files and directories to be deleted and issues an
|
||||
"Input ignore patterns>>" prompt. You can input space-seperated
|
||||
"Input ignore patterns>>" prompt. You can input space-separated
|
||||
patterns to exclude files and directories from deletion.
|
||||
E.g. "*.c *.h" will excludes files end with ".c" and ".h" from
|
||||
deletion. When you are satisfied with the filtered result, press
|
||||
|
|
|
@ -219,7 +219,7 @@ Problems related to tags:
|
|||
* Multiple tags on the same revision are not imported.
|
||||
|
||||
If you suspect that any of these issues may apply to the repository you
|
||||
want to imort, consider using cvs2git:
|
||||
want to import, consider using cvs2git:
|
||||
|
||||
* cvs2git (part of cvs2svn), `http://subversion.apache.org/`
|
||||
|
||||
|
|
|
@ -110,7 +110,7 @@ to allow writes to, for example:
|
|||
authdb = /etc/cvsserver/passwd
|
||||
|
||||
------
|
||||
The format of these files is username followed by the crypted password,
|
||||
The format of these files is username followed by the encrypted password,
|
||||
for example:
|
||||
|
||||
------
|
||||
|
|
|
@ -451,8 +451,8 @@ characteristics:
|
|||
|
||||
* By default The BFG takes full advantage of multi-core machines,
|
||||
cleansing commit file-trees in parallel. git-filter-branch cleans
|
||||
commits sequentially (ie in a single-threaded manner), though it
|
||||
_is_ possible to write filters that include their own parallellism,
|
||||
commits sequentially (i.e. in a single-threaded manner), though it
|
||||
_is_ possible to write filters that include their own parallelism,
|
||||
in the scripts executed against each commit.
|
||||
|
||||
* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options]
|
||||
|
|
|
@ -3,7 +3,7 @@ git-interpret-trailers(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-interpret-trailers - help add stuctured information into commit messages
|
||||
git-interpret-trailers - help add structured information into commit messages
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
|
@ -43,7 +43,7 @@ This means that the trimmed <token> and <value> will be separated by
|
|||
|
||||
By default the new trailer will appear at the end of all the existing
|
||||
trailers. If there is no existing trailer, the new trailer will appear
|
||||
after the commit message part of the ouput, and, if there is no line
|
||||
after the commit message part of the output, and, if there is no line
|
||||
with only spaces at the end of the commit message part, one blank line
|
||||
will be added before the new trailer.
|
||||
|
||||
|
@ -56,7 +56,7 @@ minus signs start the patch part of the message.
|
|||
|
||||
When reading trailers, there can be whitespaces before and after the
|
||||
token, the separator and the value. There can also be whitespaces
|
||||
indide the token and the value.
|
||||
inside the token and the value.
|
||||
|
||||
Note that 'trailers' do not follow and are not intended to follow many
|
||||
rules for RFC 822 headers. For example they do not follow the line
|
||||
|
|
|
@ -184,7 +184,7 @@ shown. If the pattern does not contain a globbing character (`?`,
|
|||
consider. Repetitions of this option accumulate exclusion patterns
|
||||
up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
|
||||
`--glob` option (other options or arguments do not clear
|
||||
accumlated patterns).
|
||||
accumulated patterns).
|
||||
+
|
||||
The patterns given should not begin with `refs/heads`, `refs/tags`, or
|
||||
`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
|
||||
|
|
|
@ -70,8 +70,8 @@ COMMANDS
|
|||
--username=<user>;;
|
||||
For transports that SVN handles authentication for (http,
|
||||
https, and plain svn), specify the username. For other
|
||||
transports (eg svn+ssh://), you must include the username in
|
||||
the URL, eg svn+ssh://foo@svn.bar.com/project
|
||||
transports (e.g. svn+ssh://), you must include the username in
|
||||
the URL, e.g. svn+ssh://foo@svn.bar.com/project
|
||||
--prefix=<prefix>;;
|
||||
This allows one to specify a prefix which is prepended
|
||||
to the names of remotes if trunk/branches/tags are
|
||||
|
|
|
@ -170,7 +170,7 @@ may not support it yet.
|
|||
split-index mode is already enabled and `--split-index` is
|
||||
given again, all changes in $GIT_DIR/index are pushed back to
|
||||
the shared index file. This mode is designed for very large
|
||||
indexes that take a signficant amount of time to read or write.
|
||||
indexes that take a significant amount of time to read or write.
|
||||
|
||||
\--::
|
||||
Do not interpret any more arguments as options.
|
||||
|
|
|
@ -665,7 +665,7 @@ data by examining the beginning of the contents. However, sometimes you
|
|||
may want to override its decision, either because a blob contains binary
|
||||
data later in the file, or because the content, while technically
|
||||
composed of text characters, is opaque to a human reader. For example,
|
||||
many postscript files contain only ascii characters, but produce noisy
|
||||
many postscript files contain only ASCII characters, but produce noisy
|
||||
and meaningless diffs.
|
||||
|
||||
The simplest way to mark a file as binary is to unset the diff
|
||||
|
@ -680,7 +680,7 @@ patch, if binary patches are enabled) instead of a regular diff.
|
|||
|
||||
However, one may also want to specify other diff driver attributes. For
|
||||
example, you might want to use `textconv` to convert postscript files to
|
||||
an ascii representation for human viewing, but otherwise treat them as
|
||||
an ASCII representation for human viewing, but otherwise treat them as
|
||||
binary files. You cannot specify both `-diff` and `diff=ps` attributes.
|
||||
The solution is to use the `diff.*.binary` config option:
|
||||
|
||||
|
|
|
@ -175,7 +175,7 @@ if the merge failed due to conflicts.
|
|||
|
||||
This hook can be used in conjunction with a corresponding pre-commit hook to
|
||||
save and restore any form of metadata associated with the working tree
|
||||
(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
|
||||
(e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
|
||||
for an example of how to do this.
|
||||
|
||||
pre-push
|
||||
|
|
|
@ -329,7 +329,7 @@ short form, the leading colon `:` is followed by zero or more "magic
|
|||
signature" letters (which optionally is terminated by another colon `:`),
|
||||
and the remainder is the pattern to match against the path.
|
||||
The "magic signature" consists of ASCII symbols that are neither
|
||||
alphanumeric, glob, regex special charaters nor colon.
|
||||
alphanumeric, glob, regex special characters nor colon.
|
||||
The optional colon that terminates the "magic signature" can be
|
||||
omitted if the pattern begins with a character that does not belong to
|
||||
"magic signature" symbol set and is not a colon.
|
||||
|
|
|
@ -38,7 +38,7 @@ zlib were failing).
|
|||
Reading the zlib source code, I found that "incorrect data check" means
|
||||
that the adler-32 checksum at the end of the zlib data did not match the
|
||||
inflated data. So stepping the data through zlib would not help, as it
|
||||
did not fail until the very end, when we realize the crc does not match.
|
||||
did not fail until the very end, when we realize the CRC does not match.
|
||||
The problematic bytes could be anywhere in the object data.
|
||||
|
||||
The first thing I did was pull the broken data out of the packfile. I
|
||||
|
@ -195,7 +195,7 @@ halfway through:
|
|||
-------
|
||||
|
||||
I let it run to completion, and got a few more hits at the end (where it
|
||||
was munging the crc to match our broken data). So there was a good
|
||||
was munging the CRC to match our broken data). So there was a good
|
||||
chance this middle hit was the source of the problem.
|
||||
|
||||
I confirmed by tweaking the byte in a hex editor, zlib inflating the
|
||||
|
|
|
@ -160,7 +160,7 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
|
|||
consider. Repetitions of this option accumulate exclusion patterns
|
||||
up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
|
||||
`--glob` option (other options or arguments do not clear
|
||||
accumlated patterns).
|
||||
accumulated patterns).
|
||||
+
|
||||
The patterns given should not begin with `refs/heads`, `refs/tags`, or
|
||||
`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
|
||||
|
|
|
@ -231,5 +231,5 @@ Git index format
|
|||
on. Replaced entries may have empty path names to save space.
|
||||
|
||||
The remaining index entries after replaced ones will be added to the
|
||||
final index. These added entries are also sorted by entry namme then
|
||||
final index. These added entries are also sorted by entry name then
|
||||
stage.
|
||||
|
|
|
@ -168,7 +168,7 @@ agent capability). The `X` and `Y` strings may contain any printable
|
|||
ASCII characters except space (i.e., the byte range 32 < x < 127), and
|
||||
are typically of the form "package/version" (e.g., "git/1.8.3.1"). The
|
||||
agent strings are purely informative for statistics and debugging
|
||||
purposes, and MUST NOT be used to programatically assume the presence
|
||||
purposes, and MUST NOT be used to programmatically assume the presence
|
||||
or absence of particular features.
|
||||
|
||||
shallow
|
||||
|
|
|
@ -114,7 +114,7 @@ split::
|
|||
want.
|
||||
|
||||
Repeated splits of exactly the same history are
|
||||
guaranteed to be identical (ie. to produce the same
|
||||
guaranteed to be identical (i.e. to produce the same
|
||||
commit ids). Because of this, if you add new commits
|
||||
and then re-split, the new commits will be attached as
|
||||
commits on top of the history you generated last time,
|
||||
|
|
Загрузка…
Ссылка в новой задаче