1
0
mirror of https://github.com/git/git.git synced 2024-09-28 10:00:54 +02:00

fix doc typos

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jim Meyering 2008-01-29 20:38:55 +01:00 committed by Junio C Hamano
parent bda3a31cc7
commit a5d86f7406
5 changed files with 8 additions and 8 deletions

View File

@ -12,7 +12,7 @@ Fixes since v1.5.3.2
* The default shell on some FreeBSD did not execute the
argument parsing code correctly and made git unusable.
* git-svn incorrectly spawned pager even when the user user
* git-svn incorrectly spawned pager even when the user
explicitly asked not to.
* sample post-receive hook overquoted the envelope sender

View File

@ -130,7 +130,7 @@ See also <<FILES>>.
-z, --null::
For all options that output values and/or keys, always
end values with with the null character (instead of a
end values with the null character (instead of a
newline). Use newline instead as a delimiter between
key and value. This allows for secure parsing of the
output without getting confused e.g. by values that

View File

@ -204,7 +204,7 @@ about `DBI->connect()`.
gitcvs.dbname::
Database name. The exact meaning depends on the
used database driver, for SQLite this is a filename.
selected database driver, for SQLite this is a filename.
Supports variable substitution (see below). May
not contain semicolons (`;`).
Default: '%Ggitcvs.%m.sqlite'
@ -215,7 +215,7 @@ gitcvs.dbdriver::
with 'DBD::SQLite', reported to work with
'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
Please regard this as an experimental feature. May not
contain double colons (`:`).
contain colons (`:`).
Default: 'SQLite'
gitcvs.dbuser::

View File

@ -229,13 +229,13 @@ blobs contained in a commit.
* A colon, optionally followed by a stage number (0 to 3) and a
colon, followed by a path; this names a blob object in the
index at the given path. Missing stage number (and the colon
that follows it) names an stage 0 entry. During a merge, stage
that follows it) names a stage 0 entry. During a merge, stage
1 is the common ancestor, stage 2 is the target branch's version
(typically the current branch), and stage 3 is the version from
the branch being merged.
Here is an illustration, by Jon Loeliger. Both node B and C are
a commit parents of commit node A. Parent commits are ordered
commit parents of commit node A. Parent commits are ordered
left-to-right.
G H I J
@ -291,7 +291,7 @@ and its parent commits exists. `r1{caret}@` notation means all
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
its all parents.
Here are a handful examples:
Here are a handful of examples:
D G H D
D F G H I J D F

View File

@ -184,7 +184,7 @@ In a large project where raciness avoidance cost really matters,
however, the initial computation of all object names in the
index takes more than one second, and the index file is written
out after all that happens. Therefore the timestamp of the
index file will be more than one seconds later than the the
index file will be more than one seconds later than the
youngest file in the working tree. This means that in these
cases there actually will not be any racily clean entry in
the resulting index.