Finish each sentence with a full stop.
Instead of saying 'directory index' 'directory cache' etc,
consistently say 'index'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extract commit ID from an archive created using git-tar-tree.
gitlink:git-mailinfo[1]::
Extracts patch from a single e-mail message.
Extracts patch and authorship information from a single
e-mail message, optionally transliterating the commit
message into utf-8.
gitlink:git-mailsplit[1]::
git-mailsplit.
A stupid program to split UNIX mbox format mailbox into
individual pieces of e-mail.
gitlink:git-patch-id[1]::
Compute unique ID for a patch.
gitlink:git-parse-remote[1]::
Routines to help parsing $GIT_DIR/remotes/
Routines to help parsing `$GIT_DIR/remotes/` files.
gitlink:git-request-pull[1]::
git-request-pull.
@ -406,22 +419,20 @@ Commands not yet documented
@@ -406,22 +419,20 @@ Commands not yet documented
---------------------------
gitlink:gitk[1]::
gitk.
The gitk repository browser.
Configuration Mechanism
-----------------------
Starting from 0.99.9 (actually mid 0.99.8.GIT), .git/config file
Starting from 0.99.9 (actually mid 0.99.8.GIT), `.git/config` file
is used to hold per-repository configuration options. It is a
simple text file modelled after `.ini` format familiar to some
people. Here is an example:
------------
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
# A '#' or ';' character indicates a comment.
#
; core variables
@ -443,30 +454,30 @@ their operation accordingly.
@@ -443,30 +454,30 @@ their operation accordingly.
Identifier Terminology
----------------------
<object>::
Indicates the sha1 identifier for any type of object
Indicates the object name for any type of object.
<blob>::
Indicates a blob object sha1 identifier
Indicates a blob object name.
<tree>::
Indicates a tree object sha1 identifier
Indicates a tree object name.
<commit>::
Indicates a commit object sha1 identifier
Indicates a commit object name.
<tree-ish>::
Indicates a tree, commit or tag object sha1 identifier. A
Indicates a tree, commit or tag object name. A
command that takes a <tree-ish> argument ultimately wants to
operate on a <tree> object but automatically dereferences
<commit> and <tag> objects that point at a <tree>.
<type>::
Indicates that an object type is required.
Currently one of: blob/tree/commit/tag
Currently one of: `blob`, `tree`, `commit`, or `tag`.
<file>::
Indicates a filename - always relative to the root of
the tree structure GIT_INDEX_FILE describes.
Indicates a filename - almost always relative to the
root of the tree structure `GIT_INDEX_FILE` describes.
Symbolic Identifiers
--------------------
@ -474,17 +485,20 @@ Any git command accepting any <object> can also use the following
@@ -474,17 +485,20 @@ Any git command accepting any <object> can also use the following
symbolic notation:
HEAD::
indicates the head of the repository (ie the contents of
`$GIT_DIR/HEAD`)
indicates the head of the current branch (i.e. the
contents of `$GIT_DIR/HEAD`).
<tag>::
a valid tag 'name'+
(ie the contents of `$GIT_DIR/refs/tags/<tag>`)
a valid tag 'name'
(i.e. the contents of `$GIT_DIR/refs/tags/<tag>`).
<head>::
a valid head 'name'+
(ie the contents of `$GIT_DIR/refs/heads/<head>`)
a valid head 'name'
(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
<snap>::
a valid snapshot 'name'+
(ie the contents of `$GIT_DIR/refs/snap/<snap>`)
a valid snapshot 'name'
(i.e. the contents of `$GIT_DIR/refs/snap/<snap>`).
@ -35,7 +35,7 @@ the object (i.e. how it is used, and how it can refer to other
@@ -35,7 +35,7 @@ the object (i.e. how it is used, and how it can refer to other
objects). There are currently four different object types: "blob",
"tree", "commit" and "tag".
A "blob" object cannot refer to any other object, and is, like the tag
A "blob" object cannot refer to any other object, and is, like the type
implies, a pure storage object containing some user data. It is used to
actually store the file data, i.e. a blob object is associated with some
particular version of some file.
@ -64,7 +64,7 @@ symbolic name (of course!) and, optionally, a signature.
@@ -64,7 +64,7 @@ symbolic name (of course!) and, optionally, a signature.
Regardless of object type, all objects share the following
characteristics: they are all deflated with zlib, and have a header
that not only specifies their tag, but also provides size information
that not only specifies their type, but also provides size information
about the data in the object. It's worth noting that the SHA1 hash
that is used to name the object is the hash of the original data
plus this header, so `sha1sum` 'file' does not match the object name
@ -76,7 +76,7 @@ As a result, the general consistency of an object can always be tested
@@ -76,7 +76,7 @@ As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
forms a sequence of <ascii tag without space> + <space> + <ascii decimal
forms a sequence of <ascii type without space> + <space> + <ascii decimal
size> + <byte\0> + <binary object data>.
The structured objects can further have their structure and
@ -297,7 +297,7 @@ will not normally add totally new entries or remove old entries,
@@ -297,7 +297,7 @@ will not normally add totally new entries or remove old entries,
i.e. it will normally just update existing cache entries.
To tell git that yes, you really do realize that certain files no
longer exist in the archive, or that new files should be added, you
longer exist, or that new files should be added, you
should use the `--remove` and `--add` flags respectively.
NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
@ -515,8 +515,11 @@ index file, and you can just write the result out with
@@ -515,8 +515,11 @@ index file, and you can just write the result out with
Historical note. We did not have `-u` facility when this
section was first written, so we used to warn that
the merge is done in the index file, not in your
working directory, and your working directory will no longer match your
index.
working tree, and your working tree will not match your
index after this step.
This is no longer true. The above command, thanks to `-u`
option, updates your working tree with the merge results for
paths that have been trivially merged.
8) Merging multiple trees, continued
@ -579,7 +582,7 @@ The above is the description of a git merge at the lowest level,
@@ -579,7 +582,7 @@ The above is the description of a git merge at the lowest level,
to help you understand what conceptually happens under the hood.
In practice, nobody, not even git itself, uses three `git-cat-file`
for this. There is `git-merge-index` program that extracts the
stages to temporary files and calls a `merge` script on it
stages to temporary files and calls a "merge" script on it: