Commit f745acb0 authored by Thomas Ackermann's avatar Thomas Ackermann Committed by Junio C Hamano

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: default avatarThomas Ackermann <[email protected]>
Signed-off-by: default avatarJunio C Hamano <[email protected]>
parent dd835216
......@@ -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://[email protected]/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://[email protected]/project
transports (e.g. svn+ssh://), you must include the username in
the URL, e.g. svn+ssh://[email protected]/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,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment