mirror of
https://github.com/git/git
synced 2024-08-25 02:35:46 +00:00
Merge branch 'ta/glossary'
* ta/glossary: glossary: improve definitions of refspec and pathspec The name of the hash function is "SHA-1", not "SHA1" glossary: improve description of SHA-1 related topics glossary: remove outdated/misleading/irrelevant entries
This commit is contained in:
commit
ad77690fe4
|
@ -412,7 +412,7 @@ repository's usual working tree).
|
||||||
core.logAllRefUpdates::
|
core.logAllRefUpdates::
|
||||||
Enable the reflog. Updates to a ref <ref> is logged to the file
|
Enable the reflog. Updates to a ref <ref> is logged to the file
|
||||||
"$GIT_DIR/logs/<ref>", by appending the new and old
|
"$GIT_DIR/logs/<ref>", by appending the new and old
|
||||||
SHA1, the date/time and the reason of the update, but
|
SHA-1, the date/time and the reason of the update, but
|
||||||
only when the file exists. If this configuration
|
only when the file exists. If this configuration
|
||||||
variable is set to true, missing "$GIT_DIR/logs/<ref>"
|
variable is set to true, missing "$GIT_DIR/logs/<ref>"
|
||||||
file is automatically created for branch heads (i.e. under
|
file is automatically created for branch heads (i.e. under
|
||||||
|
|
|
@ -20,7 +20,7 @@ object type, or '-s' is used to find the object size, or '--textconv' is used
|
||||||
(which implies type "blob").
|
(which implies type "blob").
|
||||||
|
|
||||||
In the second form, a list of objects (separated by linefeeds) is provided on
|
In the second form, a list of objects (separated by linefeeds) is provided on
|
||||||
stdin, and the SHA1, type, and size of each object is printed on stdout.
|
stdin, and the SHA-1, type, and size of each object is printed on stdout.
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
|
@ -58,11 +58,11 @@ OPTIONS
|
||||||
to apply the filter to the content recorded in the index at <path>.
|
to apply the filter to the content recorded in the index at <path>.
|
||||||
|
|
||||||
--batch::
|
--batch::
|
||||||
Print the SHA1, type, size, and contents of each object provided on
|
Print the SHA-1, type, size, and contents of each object provided on
|
||||||
stdin. May not be combined with any other options or arguments.
|
stdin. May not be combined with any other options or arguments.
|
||||||
|
|
||||||
--batch-check::
|
--batch-check::
|
||||||
Print the SHA1, type, and size of each object provided on stdin. May not
|
Print the SHA-1, type, and size of each object provided on stdin. May not
|
||||||
be combined with any other options or arguments.
|
be combined with any other options or arguments.
|
||||||
|
|
||||||
OUTPUT
|
OUTPUT
|
||||||
|
|
|
@ -149,7 +149,7 @@ is found, its name will be output and searching will stop.
|
||||||
If an exact match was not found, 'git describe' will walk back
|
If an exact match was not found, 'git describe' will walk back
|
||||||
through the commit history to locate an ancestor commit which
|
through the commit history to locate an ancestor commit which
|
||||||
has been tagged. The ancestor's tag will be output along with an
|
has been tagged. The ancestor's tag will be output along with an
|
||||||
abbreviation of the input committish's SHA1.
|
abbreviation of the input committish's SHA-1.
|
||||||
|
|
||||||
If multiple tags were found during the walk then the tag which
|
If multiple tags were found during the walk then the tag which
|
||||||
has the fewest commits different from the input committish will be
|
has the fewest commits different from the input committish will be
|
||||||
|
|
|
@ -23,7 +23,7 @@ OPTIONS
|
||||||
An object to treat as the head of an unreachability trace.
|
An object to treat as the head of an unreachability trace.
|
||||||
+
|
+
|
||||||
If no objects are given, 'git fsck' defaults to using the
|
If no objects are given, 'git fsck' defaults to using the
|
||||||
index file, all SHA1 references in `refs` namespace, and all reflogs
|
index file, all SHA-1 references in `refs` namespace, and all reflogs
|
||||||
(unless --no-reflogs is given) as heads.
|
(unless --no-reflogs is given) as heads.
|
||||||
|
|
||||||
--unreachable::
|
--unreachable::
|
||||||
|
@ -89,7 +89,7 @@ index file, all SHA1 references in `refs` namespace, and all reflogs
|
||||||
DISCUSSION
|
DISCUSSION
|
||||||
----------
|
----------
|
||||||
|
|
||||||
git-fsck tests SHA1 and general object sanity, and it does full tracking
|
git-fsck tests SHA-1 and general object sanity, and it does full tracking
|
||||||
of the resulting reachability and everything else. It prints out any
|
of the resulting reachability and everything else. It prints out any
|
||||||
corruption it finds (missing or bad objects), and if you use the
|
corruption it finds (missing or bad objects), and if you use the
|
||||||
'--unreachable' flag it will also print out objects that exist but that
|
'--unreachable' flag it will also print out objects that exist but that
|
||||||
|
|
|
@ -89,7 +89,7 @@ Note
|
||||||
----
|
----
|
||||||
|
|
||||||
Once the index has been created, the list of object names is sorted
|
Once the index has been created, the list of object names is sorted
|
||||||
and the SHA1 hash of that list is printed to stdout. If --stdin was
|
and the SHA-1 hash of that list is printed to stdout. If --stdin was
|
||||||
also used then this is prefixed by either "pack\t", or "keep\t" if a
|
also used then this is prefixed by either "pack\t", or "keep\t" if a
|
||||||
new .keep file was successfully created. This is useful to remove a
|
new .keep file was successfully created. This is useful to remove a
|
||||||
.keep file used as a lock to prevent the race with 'git repack'
|
.keep file used as a lock to prevent the race with 'git repack'
|
||||||
|
|
|
@ -164,7 +164,7 @@ which case it outputs:
|
||||||
'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
|
'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
|
||||||
detailed information on unmerged paths.
|
detailed information on unmerged paths.
|
||||||
|
|
||||||
For an unmerged path, instead of recording a single mode/SHA1 pair,
|
For an unmerged path, instead of recording a single mode/SHA-1 pair,
|
||||||
the index records up to three such pairs; one from tree O in stage
|
the index records up to three such pairs; one from tree O in stage
|
||||||
1, A in stage 2, and B in stage 3. This information can be used by
|
1, A in stage 2, and B in stage 3. This information can be used by
|
||||||
the user (or the porcelain) to see what should eventually be recorded at the
|
the user (or the porcelain) to see what should eventually be recorded at the
|
||||||
|
|
|
@ -14,7 +14,7 @@ SYNOPSIS
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
This looks up the <file>(s) in the index and, if there are any merge
|
This looks up the <file>(s) in the index and, if there are any merge
|
||||||
entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty
|
entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty
|
||||||
argument if no file), and <file> as argument 4. File modes for the three
|
argument if no file), and <file> as argument 4. File modes for the three
|
||||||
files are passed as arguments 5, 6 and 7.
|
files are passed as arguments 5, 6 and 7.
|
||||||
|
|
||||||
|
|
|
@ -50,7 +50,7 @@ base-name::
|
||||||
Write into a pair of files (.pack and .idx), using
|
Write into a pair of files (.pack and .idx), using
|
||||||
<base-name> to determine the name of the created file.
|
<base-name> to determine the name of the created file.
|
||||||
When this option is used, the two files are written in
|
When this option is used, the two files are written in
|
||||||
<base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash
|
<base-name>-<SHA-1>.{pack,idx} files. <SHA-1> is a hash
|
||||||
of the sorted object names to make the resulting filename
|
of the sorted object names to make the resulting filename
|
||||||
based on the pack content, and written to the standard
|
based on the pack content, and written to the standard
|
||||||
output of the command.
|
output of the command.
|
||||||
|
|
|
@ -12,7 +12,7 @@ SYNOPSIS
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
|
A "patch ID" is nothing but a SHA-1 of the diff associated with a patch, with
|
||||||
whitespace and line numbers ignored. As such, it's "reasonably stable", but at
|
whitespace and line numbers ignored. As such, it's "reasonably stable", but at
|
||||||
the same time also reasonably unique, i.e., two patches that have the same "patch
|
the same time also reasonably unique, i.e., two patches that have the same "patch
|
||||||
ID" are almost guaranteed to be the same thing.
|
ID" are almost guaranteed to be the same thing.
|
||||||
|
|
|
@ -16,8 +16,8 @@ DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
Adds a 'replace' reference in `refs/replace/` namespace.
|
Adds a 'replace' reference in `refs/replace/` namespace.
|
||||||
|
|
||||||
The name of the 'replace' reference is the SHA1 of the object that is
|
The name of the 'replace' reference is the SHA-1 of the object that is
|
||||||
replaced. The content of the 'replace' reference is the SHA1 of the
|
replaced. The content of the 'replace' reference is the SHA-1 of the
|
||||||
replacement object.
|
replacement object.
|
||||||
|
|
||||||
Unless `-f` is given, the 'replace' reference must not yet exist.
|
Unless `-f` is given, the 'replace' reference must not yet exist.
|
||||||
|
|
|
@ -95,7 +95,7 @@ can be used.
|
||||||
one.
|
one.
|
||||||
|
|
||||||
--symbolic::
|
--symbolic::
|
||||||
Usually the object names are output in SHA1 form (with
|
Usually the object names are output in SHA-1 form (with
|
||||||
possible '{caret}' prefix); this option makes them output in a
|
possible '{caret}' prefix); this option makes them output in a
|
||||||
form as close to the original input as possible.
|
form as close to the original input as possible.
|
||||||
|
|
||||||
|
@ -180,7 +180,7 @@ print a message to stderr and exit with nonzero status.
|
||||||
|
|
||||||
--short::
|
--short::
|
||||||
--short=number::
|
--short=number::
|
||||||
Instead of outputting the full SHA1 values of object names try to
|
Instead of outputting the full SHA-1 values of object names try to
|
||||||
abbreviate them to a shorter unique name. When no length is specified
|
abbreviate them to a shorter unique name. When no length is specified
|
||||||
7 is used. The minimum length is 4.
|
7 is used. The minimum length is 4.
|
||||||
|
|
||||||
|
|
|
@ -31,7 +31,7 @@ no <rev> nor <glob> is given on the command line.
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
<rev>::
|
<rev>::
|
||||||
Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7])
|
Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7])
|
||||||
that typically names a branch head or a tag.
|
that typically names a branch head or a tag.
|
||||||
|
|
||||||
<glob>::
|
<glob>::
|
||||||
|
@ -142,7 +142,7 @@ displayed, indented N places. If a commit is on the I-th
|
||||||
branch, the I-th indentation character shows a `+` sign;
|
branch, the I-th indentation character shows a `+` sign;
|
||||||
otherwise it shows a space. Merge commits are denoted by
|
otherwise it shows a space. Merge commits are denoted by
|
||||||
a `-` sign. Each commit shows a short name that
|
a `-` sign. Each commit shows a short name that
|
||||||
can be used as an extended SHA1 to name that commit.
|
can be used as an extended SHA-1 to name that commit.
|
||||||
|
|
||||||
The following example shows three branches, "master", "fixes"
|
The following example shows three branches, "master", "fixes"
|
||||||
and "mhf":
|
and "mhf":
|
||||||
|
|
|
@ -19,7 +19,7 @@ Reads given idx file for packed Git archive created with
|
||||||
|
|
||||||
The information it outputs is subset of what you can get from
|
The information it outputs is subset of what you can get from
|
||||||
'git verify-pack -v'; this command only shows the packfile
|
'git verify-pack -v'; this command only shows the packfile
|
||||||
offset and SHA1 of each object.
|
offset and SHA-1 of each object.
|
||||||
|
|
||||||
GIT
|
GIT
|
||||||
---
|
---
|
||||||
|
|
|
@ -50,8 +50,8 @@ OPTIONS
|
||||||
-s::
|
-s::
|
||||||
--hash[=<n>]::
|
--hash[=<n>]::
|
||||||
|
|
||||||
Only show the SHA1 hash, not the reference name. When combined with
|
Only show the SHA-1 hash, not the reference name. When combined with
|
||||||
--dereference the dereferenced tag will still be shown after the SHA1.
|
--dereference the dereferenced tag will still be shown after the SHA-1.
|
||||||
|
|
||||||
--verify::
|
--verify::
|
||||||
|
|
||||||
|
|
|
@ -33,7 +33,7 @@ in the tag message.
|
||||||
If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
|
If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`
|
||||||
are absent, `-a` is implied.
|
are absent, `-a` is implied.
|
||||||
|
|
||||||
Otherwise just a tag reference for the SHA1 object name of the commit object is
|
Otherwise just a tag reference for the SHA-1 object name of the commit object is
|
||||||
created (i.e. a lightweight tag).
|
created (i.e. a lightweight tag).
|
||||||
|
|
||||||
A GnuPG signed tag object will be created when `-s` or `-u
|
A GnuPG signed tag object will be created when `-s` or `-u
|
||||||
|
|
|
@ -247,7 +247,7 @@ $ git update-index --index-info
|
||||||
------------
|
------------
|
||||||
|
|
||||||
The first line of the input feeds 0 as the mode to remove the
|
The first line of the input feeds 0 as the mode to remove the
|
||||||
path; the SHA1 does not matter as long as it is well formatted.
|
path; the SHA-1 does not matter as long as it is well formatted.
|
||||||
Then the second and third line feeds stage 1 and stage 2 entries
|
Then the second and third line feeds stage 1 and stage 2 entries
|
||||||
for that path. After the above, we would end up with this:
|
for that path. After the above, we would end up with this:
|
||||||
|
|
||||||
|
|
|
@ -40,11 +40,11 @@ OUTPUT FORMAT
|
||||||
-------------
|
-------------
|
||||||
When specifying the -v option the format used is:
|
When specifying the -v option the format used is:
|
||||||
|
|
||||||
SHA1 type size size-in-pack-file offset-in-packfile
|
SHA-1 type size size-in-pack-file offset-in-packfile
|
||||||
|
|
||||||
for objects that are not deltified in the pack, and
|
for objects that are not deltified in the pack, and
|
||||||
|
|
||||||
SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
|
SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1
|
||||||
|
|
||||||
for objects that are deltified.
|
for objects that are deltified.
|
||||||
|
|
||||||
|
|
|
@ -21,7 +21,7 @@ OPTIONS
|
||||||
Print the contents of the tag object before validating it.
|
Print the contents of the tag object before validating it.
|
||||||
|
|
||||||
<tag>...::
|
<tag>...::
|
||||||
SHA1 identifiers of Git tag objects.
|
SHA-1 identifiers of Git tag objects.
|
||||||
|
|
||||||
GIT
|
GIT
|
||||||
---
|
---
|
||||||
|
|
|
@ -741,7 +741,7 @@ where:
|
||||||
|
|
||||||
<old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
|
<old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
|
||||||
contents of <old|new>,
|
contents of <old|new>,
|
||||||
<old|new>-hex:: are the 40-hexdigit SHA1 hashes,
|
<old|new>-hex:: are the 40-hexdigit SHA-1 hashes,
|
||||||
<old|new>-mode:: are the octal representation of the file modes.
|
<old|new>-mode:: are the octal representation of the file modes.
|
||||||
+
|
+
|
||||||
The file parameters can point at the user's working file
|
The file parameters can point at the user's working file
|
||||||
|
@ -864,7 +864,7 @@ The commit, equivalent to what other systems call a "changeset" or
|
||||||
represents an immediately preceding step. Commits with more than one
|
represents an immediately preceding step. Commits with more than one
|
||||||
parent represent merges of independent lines of development.
|
parent represent merges of independent lines of development.
|
||||||
|
|
||||||
All objects are named by the SHA1 hash of their contents, normally
|
All objects are named by the SHA-1 hash of their contents, normally
|
||||||
written as a string of 40 hex digits. Such names are globally unique.
|
written as a string of 40 hex digits. Such names are globally unique.
|
||||||
The entire history leading up to a commit can be vouched for by signing
|
The entire history leading up to a commit can be vouched for by signing
|
||||||
just that commit. A fourth object type, the tag, is provided for this
|
just that commit. A fourth object type, the tag, is provided for this
|
||||||
|
@ -874,9 +874,9 @@ When first created, objects are stored in individual files, but for
|
||||||
efficiency may later be compressed together into "pack files".
|
efficiency may later be compressed together into "pack files".
|
||||||
|
|
||||||
Named pointers called refs mark interesting points in history. A ref
|
Named pointers called refs mark interesting points in history. A ref
|
||||||
may contain the SHA1 name of an object or the name of another ref. Refs
|
may contain the SHA-1 name of an object or the name of another ref. Refs
|
||||||
with names beginning `ref/head/` contain the SHA1 name of the most
|
with names beginning `ref/head/` contain the SHA-1 name of the most
|
||||||
recent commit (or "head") of a branch under development. SHA1 names of
|
recent commit (or "head") of a branch under development. SHA-1 names of
|
||||||
tags of interest are stored under `ref/tags/`. A special ref named
|
tags of interest are stored under `ref/tags/`. A special ref named
|
||||||
`HEAD` contains the name of the currently checked-out branch.
|
`HEAD` contains the name of the currently checked-out branch.
|
||||||
|
|
||||||
|
|
|
@ -106,9 +106,9 @@ branch. A number of the Git tools will assume that `.git/HEAD` is
|
||||||
valid, though.
|
valid, though.
|
||||||
|
|
||||||
[NOTE]
|
[NOTE]
|
||||||
An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',
|
An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name',
|
||||||
and a reference to an object is always the 40-byte hex
|
and a reference to an object is always the 40-byte hex
|
||||||
representation of that SHA1 name. The files in the `refs`
|
representation of that SHA-1 name. The files in the `refs`
|
||||||
subdirectory are expected to contain these hex references
|
subdirectory are expected to contain these hex references
|
||||||
(usually with a final `\n` at the end), and you should thus
|
(usually with a final `\n` at the end), and you should thus
|
||||||
expect to see a number of 41-byte files containing these
|
expect to see a number of 41-byte files containing these
|
||||||
|
@ -763,7 +763,7 @@ already discussed, the `HEAD` branch is nothing but a symlink to one of
|
||||||
these object pointers.
|
these object pointers.
|
||||||
|
|
||||||
You can at any time create a new branch by just picking an arbitrary
|
You can at any time create a new branch by just picking an arbitrary
|
||||||
point in the project history, and just writing the SHA1 name of that
|
point in the project history, and just writing the SHA-1 name of that
|
||||||
object into a file under `.git/refs/heads/`. You can use any filename you
|
object into a file under `.git/refs/heads/`. You can use any filename you
|
||||||
want (and indeed, subdirectories), but the convention is that the
|
want (and indeed, subdirectories), but the convention is that the
|
||||||
"normal" branch is called `master`. That's just a convention, though,
|
"normal" branch is called `master`. That's just a convention, though,
|
||||||
|
@ -1233,7 +1233,7 @@ file (the first tree goes to stage 1, the second to stage 2,
|
||||||
etc.). After reading three trees into three stages, the paths
|
etc.). After reading three trees into three stages, the paths
|
||||||
that are the same in all three stages are 'collapsed' into stage
|
that are the same in all three stages are 'collapsed' into stage
|
||||||
0. Also paths that are the same in two of three stages are
|
0. Also paths that are the same in two of three stages are
|
||||||
collapsed into stage 0, taking the SHA1 from either stage 2 or
|
collapsed into stage 0, taking the SHA-1 from either stage 2 or
|
||||||
stage 3, whichever is different from stage 1 (i.e. only one side
|
stage 3, whichever is different from stage 1 (i.e. only one side
|
||||||
changed from the common ancestor).
|
changed from the common ancestor).
|
||||||
|
|
||||||
|
|
|
@ -108,7 +108,7 @@ it changes it to:
|
||||||
For the purpose of breaking a filepair, diffcore-break examines
|
For the purpose of breaking a filepair, diffcore-break examines
|
||||||
the extent of changes between the contents of the files before
|
the extent of changes between the contents of the files before
|
||||||
and after modification (i.e. the contents that have "bcd1234..."
|
and after modification (i.e. the contents that have "bcd1234..."
|
||||||
and "0123456..." as their SHA1 content ID, in the above
|
and "0123456..." as their SHA-1 content ID, in the above
|
||||||
example). The amount of deletion of original contents and
|
example). The amount of deletion of original contents and
|
||||||
insertion of new material are added together, and if it exceeds
|
insertion of new material are added together, and if it exceeds
|
||||||
the "break score", the filepair is broken into two. The break
|
the "break score", the filepair is broken into two. The break
|
||||||
|
|
|
@ -99,7 +99,7 @@ given); `template` (if a `-t` option was given or the
|
||||||
configuration option `commit.template` is set); `merge` (if the
|
configuration option `commit.template` is set); `merge` (if the
|
||||||
commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
|
commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
|
||||||
(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
|
(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
|
||||||
a commit SHA1 (if a `-c`, `-C` or `--amend` option was given).
|
a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given).
|
||||||
|
|
||||||
If the exit status is non-zero, 'git commit' will abort.
|
If the exit status is non-zero, 'git commit' will abort.
|
||||||
|
|
||||||
|
@ -196,11 +196,11 @@ hook would receive a line like the following:
|
||||||
|
|
||||||
refs/heads/master 67890 refs/heads/foreign 12345
|
refs/heads/master 67890 refs/heads/foreign 12345
|
||||||
|
|
||||||
although the full, 40-character SHA1s would be supplied. If the foreign ref
|
although the full, 40-character SHA-1s would be supplied. If the foreign ref
|
||||||
does not yet exist the `<remote SHA1>` will be 40 `0`. If a ref is to be
|
does not yet exist the `<remote SHA-1>` will be 40 `0`. If a ref is to be
|
||||||
deleted, the `<local ref>` will be supplied as `(delete)` and the `<local
|
deleted, the `<local ref>` will be supplied as `(delete)` and the `<local
|
||||||
SHA1>` will be 40 `0`. If the local commit was specified by something other
|
SHA-1>` will be 40 `0`. If the local commit was specified by something other
|
||||||
than a name which could be expanded (such as `HEAD~`, or a SHA1) it will be
|
than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be
|
||||||
supplied as it was originally given.
|
supplied as it was originally given.
|
||||||
|
|
||||||
If this hook exits with a non-zero status, 'git push' will abort without
|
If this hook exits with a non-zero status, 'git push' will abort without
|
||||||
|
|
|
@ -106,7 +106,7 @@ refs/remotes/`name`::
|
||||||
from a remote repository.
|
from a remote repository.
|
||||||
|
|
||||||
refs/replace/`<obj-sha1>`::
|
refs/replace/`<obj-sha1>`::
|
||||||
records the SHA1 of the object that replaces `<obj-sha1>`.
|
records the SHA-1 of the object that replaces `<obj-sha1>`.
|
||||||
This is similar to info/grafts and is internally used and
|
This is similar to info/grafts and is internally used and
|
||||||
maintained by linkgit:git-replace[1]. Such refs can be exchanged
|
maintained by linkgit:git-replace[1]. Such refs can be exchanged
|
||||||
between repositories while grafts are not.
|
between repositories while grafts are not.
|
||||||
|
|
|
@ -46,9 +46,9 @@ What are the 7 digits of hex that Git responded to the commit with?
|
||||||
|
|
||||||
We saw in part one of the tutorial that commits have names like this.
|
We saw in part one of the tutorial that commits have names like this.
|
||||||
It turns out that every object in the Git history is stored under
|
It turns out that every object in the Git history is stored under
|
||||||
a 40-digit hex name. That name is the SHA1 hash of the object's
|
a 40-digit hex name. That name is the SHA-1 hash of the object's
|
||||||
contents; among other things, this ensures that Git will never store
|
contents; among other things, this ensures that Git will never store
|
||||||
the same data twice (since identical data is given an identical SHA1
|
the same data twice (since identical data is given an identical SHA-1
|
||||||
name), and that the contents of a Git object will never change (since
|
name), and that the contents of a Git object will never change (since
|
||||||
that would change the object's name as well). The 7 char hex strings
|
that would change the object's name as well). The 7 char hex strings
|
||||||
here are simply the abbreviation of such 40 character long strings.
|
here are simply the abbreviation of such 40 character long strings.
|
||||||
|
@ -56,7 +56,7 @@ Abbreviations can be used everywhere where the 40 character strings
|
||||||
can be used, so long as they are unambiguous.
|
can be used, so long as they are unambiguous.
|
||||||
|
|
||||||
It is expected that the content of the commit object you created while
|
It is expected that the content of the commit object you created while
|
||||||
following the example above generates a different SHA1 hash than
|
following the example above generates a different SHA-1 hash than
|
||||||
the one shown above because the commit object records the time when
|
the one shown above because the commit object records the time when
|
||||||
it was created and the name of the person performing the commit.
|
it was created and the name of the person performing the commit.
|
||||||
|
|
||||||
|
@ -80,14 +80,14 @@ A tree can refer to one or more "blob" objects, each corresponding to
|
||||||
a file. In addition, a tree can also refer to other tree objects,
|
a file. In addition, a tree can also refer to other tree objects,
|
||||||
thus creating a directory hierarchy. You can examine the contents of
|
thus creating a directory hierarchy. You can examine the contents of
|
||||||
any tree using ls-tree (remember that a long enough initial portion
|
any tree using ls-tree (remember that a long enough initial portion
|
||||||
of the SHA1 will also work):
|
of the SHA-1 will also work):
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
$ git ls-tree 92b8b694
|
$ git ls-tree 92b8b694
|
||||||
100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
|
100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
Thus we see that this tree has one file in it. The SHA1 hash is a
|
Thus we see that this tree has one file in it. The SHA-1 hash is a
|
||||||
reference to that file's data:
|
reference to that file's data:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
@ -106,7 +106,7 @@ Note that this is the old file data; so the object that Git named in
|
||||||
its response to the initial tree was a tree with a snapshot of the
|
its response to the initial tree was a tree with a snapshot of the
|
||||||
directory state that was recorded by the first commit.
|
directory state that was recorded by the first commit.
|
||||||
|
|
||||||
All of these objects are stored under their SHA1 names inside the Git
|
All of these objects are stored under their SHA-1 names inside the Git
|
||||||
directory:
|
directory:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
@ -142,7 +142,7 @@ ref: refs/heads/master
|
||||||
|
|
||||||
As you can see, this tells us which branch we're currently on, and it
|
As you can see, this tells us which branch we're currently on, and it
|
||||||
tells us this by naming a file under the .git directory, which itself
|
tells us this by naming a file under the .git directory, which itself
|
||||||
contains a SHA1 name referring to a commit object, which we can
|
contains a SHA-1 name referring to a commit object, which we can
|
||||||
examine with cat-file:
|
examine with cat-file:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
@ -208,7 +208,7 @@ project's history:
|
||||||
|
|
||||||
Note, by the way, that lots of commands take a tree as an argument.
|
Note, by the way, that lots of commands take a tree as an argument.
|
||||||
But as we can see above, a tree can be referred to in many different
|
But as we can see above, a tree can be referred to in many different
|
||||||
ways--by the SHA1 name for that tree, by the name of a commit that
|
ways--by the SHA-1 name for that tree, by the name of a commit that
|
||||||
refers to the tree, by the name of a branch whose head refers to that
|
refers to the tree, by the name of a branch whose head refers to that
|
||||||
tree, etc.--and most such commands can accept any of these names.
|
tree, etc.--and most such commands can accept any of these names.
|
||||||
|
|
||||||
|
|
|
@ -117,9 +117,6 @@ branch --set-upstream-to` that sets what remote tracking branch the
|
||||||
current branch integrates with) obviously do not work, as there is no
|
current branch integrates with) obviously do not work, as there is no
|
||||||
(real) current branch to ask about in this state.
|
(real) current branch to ask about in this state.
|
||||||
|
|
||||||
[[def_dircache]]dircache::
|
|
||||||
You are *waaaaay* behind. See <<def_index,index>>.
|
|
||||||
|
|
||||||
[[def_directory]]directory::
|
[[def_directory]]directory::
|
||||||
The list you get with "ls" :-)
|
The list you get with "ls" :-)
|
||||||
|
|
||||||
|
@ -128,11 +125,6 @@ current branch integrates with) obviously do not work, as there is no
|
||||||
it contains modifications which have not been <<def_commit,committed>> to the current
|
it contains modifications which have not been <<def_commit,committed>> to the current
|
||||||
<<def_branch,branch>>.
|
<<def_branch,branch>>.
|
||||||
|
|
||||||
[[def_ent]]ent::
|
|
||||||
Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See
|
|
||||||
http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
|
|
||||||
explanation. Avoid this term, not to confuse people.
|
|
||||||
|
|
||||||
[[def_evil_merge]]evil merge::
|
[[def_evil_merge]]evil merge::
|
||||||
An evil merge is a <<def_merge,merge>> that introduces changes that
|
An evil merge is a <<def_merge,merge>> that introduces changes that
|
||||||
do not appear in any <<def_parent,parent>>.
|
do not appear in any <<def_parent,parent>>.
|
||||||
|
@ -174,7 +166,7 @@ current branch integrates with) obviously do not work, as there is no
|
||||||
created. Configured via the `.git/info/grafts` file.
|
created. Configured via the `.git/info/grafts` file.
|
||||||
|
|
||||||
[[def_hash]]hash::
|
[[def_hash]]hash::
|
||||||
In Git's context, synonym to <<def_object_name,object name>>.
|
In Git's context, synonym for <<def_object_name,object name>>.
|
||||||
|
|
||||||
[[def_head]]head::
|
[[def_head]]head::
|
||||||
A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
|
A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
|
||||||
|
@ -246,7 +238,7 @@ This commit is referred to as a "merge commit", or sometimes just a
|
||||||
|
|
||||||
[[def_object]]object::
|
[[def_object]]object::
|
||||||
The unit of storage in Git. It is uniquely identified by the
|
The unit of storage in Git. It is uniquely identified by the
|
||||||
<<def_SHA1,SHA1>> of its contents. Consequently, an
|
<<def_SHA1,SHA-1>> of its contents. Consequently, an
|
||||||
object can not be changed.
|
object can not be changed.
|
||||||
|
|
||||||
[[def_object_database]]object database::
|
[[def_object_database]]object database::
|
||||||
|
@ -258,10 +250,9 @@ This commit is referred to as a "merge commit", or sometimes just a
|
||||||
Synonym for <<def_object_name,object name>>.
|
Synonym for <<def_object_name,object name>>.
|
||||||
|
|
||||||
[[def_object_name]]object name::
|
[[def_object_name]]object name::
|
||||||
The unique identifier of an <<def_object,object>>. The <<def_hash,hash>>
|
The unique identifier of an <<def_object,object>>. The
|
||||||
of the object's contents using the Secure Hash Algorithm
|
object name is usually represented by a 40 character
|
||||||
1 and usually represented by the 40 character hexadecimal encoding of
|
hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>.
|
||||||
the <<def_hash,hash>> of the object.
|
|
||||||
|
|
||||||
[[def_object_type]]object type::
|
[[def_object_type]]object type::
|
||||||
One of the identifiers "<<def_commit_object,commit>>",
|
One of the identifiers "<<def_commit_object,commit>>",
|
||||||
|
@ -270,8 +261,7 @@ This commit is referred to as a "merge commit", or sometimes just a
|
||||||
<<def_object,object>>.
|
<<def_object,object>>.
|
||||||
|
|
||||||
[[def_octopus]]octopus::
|
[[def_octopus]]octopus::
|
||||||
To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an
|
To <<def_merge,merge>> more than two <<def_branch,branches>>.
|
||||||
intelligent predator.
|
|
||||||
|
|
||||||
[[def_origin]]origin::
|
[[def_origin]]origin::
|
||||||
The default upstream <<def_repository,repository>>. Most projects have
|
The default upstream <<def_repository,repository>>. Most projects have
|
||||||
|
@ -291,7 +281,7 @@ This commit is referred to as a "merge commit", or sometimes just a
|
||||||
pack.
|
pack.
|
||||||
|
|
||||||
[[def_pathspec]]pathspec::
|
[[def_pathspec]]pathspec::
|
||||||
Pattern used to specify paths.
|
Pattern used to limit paths in Git commands.
|
||||||
+
|
+
|
||||||
Pathspecs are used on the command line of "git ls-files", "git
|
Pathspecs are used on the command line of "git ls-files", "git
|
||||||
ls-tree", "git add", "git grep", "git diff", "git checkout",
|
ls-tree", "git add", "git grep", "git diff", "git checkout",
|
||||||
|
@ -300,6 +290,8 @@ limit the scope of operations to some subset of the tree or
|
||||||
worktree. See the documentation of each command for whether
|
worktree. See the documentation of each command for whether
|
||||||
paths are relative to the current directory or toplevel. The
|
paths are relative to the current directory or toplevel. The
|
||||||
pathspec syntax is as follows:
|
pathspec syntax is as follows:
|
||||||
|
+
|
||||||
|
--
|
||||||
|
|
||||||
* any path matches itself
|
* any path matches itself
|
||||||
* the pathspec up to the last slash represents a
|
* the pathspec up to the last slash represents a
|
||||||
|
@ -309,11 +301,12 @@ pathspec syntax is as follows:
|
||||||
of the pathname. Paths relative to the directory
|
of the pathname. Paths relative to the directory
|
||||||
prefix will be matched against that pattern using fnmatch(3);
|
prefix will be matched against that pattern using fnmatch(3);
|
||||||
in particular, '*' and '?' _can_ match directory separators.
|
in particular, '*' and '?' _can_ match directory separators.
|
||||||
|
|
||||||
|
--
|
||||||
+
|
+
|
||||||
For example, Documentation/*.jpg will match all .jpg files
|
For example, Documentation/*.jpg will match all .jpg files
|
||||||
in the Documentation subtree,
|
in the Documentation subtree,
|
||||||
including Documentation/chapter_1/figure_1.jpg.
|
including Documentation/chapter_1/figure_1.jpg.
|
||||||
|
|
||||||
+
|
+
|
||||||
A pathspec that begins with a colon `:` has special meaning. In the
|
A pathspec that begins with a colon `:` has special meaning. In the
|
||||||
short form, the leading colon `:` is followed by zero or more "magic
|
short form, the leading colon `:` is followed by zero or more "magic
|
||||||
|
@ -329,18 +322,10 @@ and a close parentheses `)`, and the remainder is the pattern to match
|
||||||
against the path.
|
against the path.
|
||||||
+
|
+
|
||||||
The "magic signature" consists of an ASCII symbol that is not
|
The "magic signature" consists of an ASCII symbol that is not
|
||||||
alphanumeric.
|
alphanumeric. Currently only the slash `/` is recognized as a
|
||||||
+
|
"magic signature": it makes the pattern match from the root of
|
||||||
--
|
the working tree, even when you are running the command from
|
||||||
top `/`;;
|
inside a subdirectory.
|
||||||
The magic word `top` (mnemonic: `/`) makes the pattern match
|
|
||||||
from the root of the working tree, even when you are running
|
|
||||||
the command from inside a subdirectory.
|
|
||||||
--
|
|
||||||
+
|
|
||||||
Currently only the slash `/` is recognized as the "magic signature",
|
|
||||||
but it is envisioned that we will support more types of magic in later
|
|
||||||
versions of Git.
|
|
||||||
+
|
+
|
||||||
A pathspec with only a colon means "there is no pathspec". This form
|
A pathspec with only a colon means "there is no pathspec". This form
|
||||||
should not be combined with other pathspec.
|
should not be combined with other pathspec.
|
||||||
|
@ -398,7 +383,7 @@ should not be combined with other pathspec.
|
||||||
to the result.
|
to the result.
|
||||||
|
|
||||||
[[def_ref]]ref::
|
[[def_ref]]ref::
|
||||||
A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
|
A 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that
|
||||||
denotes a particular <<def_object,object>>. They may be stored in
|
denotes a particular <<def_object,object>>. They may be stored in
|
||||||
a file under `$GIT_DIR/refs/` directory, or
|
a file under `$GIT_DIR/refs/` directory, or
|
||||||
in the `$GIT_DIR/packed-refs` file.
|
in the `$GIT_DIR/packed-refs` file.
|
||||||
|
@ -412,15 +397,7 @@ should not be combined with other pathspec.
|
||||||
[[def_refspec]]refspec::
|
[[def_refspec]]refspec::
|
||||||
A "refspec" is used by <<def_fetch,fetch>> and
|
A "refspec" is used by <<def_fetch,fetch>> and
|
||||||
<<def_push,push>> to describe the mapping between remote
|
<<def_push,push>> to describe the mapping between remote
|
||||||
<<def_ref,ref>> and local ref. They are combined with a colon in
|
<<def_ref,ref>> and local ref.
|
||||||
the format <src>:<dst>, preceded by an optional plus sign, +.
|
|
||||||
For example: `git fetch $URL
|
|
||||||
refs/heads/master:refs/heads/origin` means "grab the master
|
|
||||||
<<def_branch,branch>> <<def_head,head>> from the $URL and store
|
|
||||||
it as my origin branch head". And `git push
|
|
||||||
$URL refs/heads/master:refs/heads/to-upstream` means "publish my
|
|
||||||
master branch head as to-upstream branch at $URL". See also
|
|
||||||
linkgit:git-push[1].
|
|
||||||
|
|
||||||
[[def_remote_tracking_branch]]remote-tracking branch::
|
[[def_remote_tracking_branch]]remote-tracking branch::
|
||||||
A regular Git <<def_branch,branch>> that is used to follow changes from
|
A regular Git <<def_branch,branch>> that is used to follow changes from
|
||||||
|
@ -454,8 +431,9 @@ should not be combined with other pathspec.
|
||||||
[[def_SCM]]SCM::
|
[[def_SCM]]SCM::
|
||||||
Source code management (tool).
|
Source code management (tool).
|
||||||
|
|
||||||
[[def_SHA1]]SHA1::
|
[[def_SHA1]]SHA-1::
|
||||||
Synonym for <<def_object_name,object name>>.
|
"Secure Hash Algorithm 1"; a cryptographic hash function.
|
||||||
|
In the context of Git used as a synonym for <<def_object_name,object name>>.
|
||||||
|
|
||||||
[[def_shallow_repository]]shallow repository::
|
[[def_shallow_repository]]shallow repository::
|
||||||
A shallow <<def_repository,repository>> has an incomplete
|
A shallow <<def_repository,repository>> has an incomplete
|
||||||
|
@ -469,7 +447,7 @@ should not be combined with other pathspec.
|
||||||
its history can be later deepened with linkgit:git-fetch[1].
|
its history can be later deepened with linkgit:git-fetch[1].
|
||||||
|
|
||||||
[[def_symref]]symref::
|
[[def_symref]]symref::
|
||||||
Symbolic reference: instead of containing the <<def_SHA1,SHA1>>
|
Symbolic reference: instead of containing the <<def_SHA1,SHA-1>>
|
||||||
id itself, it is of the format 'ref: refs/some/thing' and when
|
id itself, it is of the format 'ref: refs/some/thing' and when
|
||||||
referenced, it recursively dereferences to this reference.
|
referenced, it recursively dereferences to this reference.
|
||||||
'<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic
|
'<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic
|
||||||
|
|
|
@ -15,7 +15,7 @@ On Fri, 9 Nov 2007, Yossi Leybovich wrote:
|
||||||
> Any one know how can I track this object and understand which file is it
|
> Any one know how can I track this object and understand which file is it
|
||||||
-----------------------------------------------------------
|
-----------------------------------------------------------
|
||||||
|
|
||||||
So exactly *because* the SHA1 hash is cryptographically secure, the hash
|
So exactly *because* the SHA-1 hash is cryptographically secure, the hash
|
||||||
itself doesn't actually tell you anything, in order to fix a corrupt
|
itself doesn't actually tell you anything, in order to fix a corrupt
|
||||||
object you basically have to find the "original source" for it.
|
object you basically have to find the "original source" for it.
|
||||||
|
|
||||||
|
@ -44,7 +44,7 @@ So:
|
||||||
-----------------------------------------------------------
|
-----------------------------------------------------------
|
||||||
|
|
||||||
This is the right thing to do, although it's usually best to save it under
|
This is the right thing to do, although it's usually best to save it under
|
||||||
it's full SHA1 name (you just dropped the "4b" from the result ;).
|
it's full SHA-1 name (you just dropped the "4b" from the result ;).
|
||||||
|
|
||||||
Let's see what that tells us:
|
Let's see what that tells us:
|
||||||
|
|
||||||
|
@ -89,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do
|
||||||
|
|
||||||
git hash-object -w my-magic-file
|
git hash-object -w my-magic-file
|
||||||
|
|
||||||
again, and if it outputs the missing SHA1 (4b945..) you're now all done!
|
again, and if it outputs the missing SHA-1 (4b945..) you're now all done!
|
||||||
|
|
||||||
But that's the really lucky case, so let's assume that it was some older
|
But that's the really lucky case, so let's assume that it was some older
|
||||||
version that was broken. How do you tell which version it was?
|
version that was broken. How do you tell which version it was?
|
||||||
|
|
|
@ -75,7 +75,7 @@ This is designed to be as compact as possible.
|
||||||
* 'raw'
|
* 'raw'
|
||||||
+
|
+
|
||||||
The 'raw' format shows the entire commit exactly as
|
The 'raw' format shows the entire commit exactly as
|
||||||
stored in the commit object. Notably, the SHA1s are
|
stored in the commit object. Notably, the SHA-1s are
|
||||||
displayed in full, regardless of whether --abbrev or
|
displayed in full, regardless of whether --abbrev or
|
||||||
--no-abbrev are used, and 'parents' information show the
|
--no-abbrev are used, and 'parents' information show the
|
||||||
true parent commits, without taking grafts nor history
|
true parent commits, without taking grafts nor history
|
||||||
|
|
|
@ -2,13 +2,13 @@ SPECIFYING REVISIONS
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
A revision parameter '<rev>' typically, but not necessarily, names a
|
A revision parameter '<rev>' typically, but not necessarily, names a
|
||||||
commit object. It uses what is called an 'extended SHA1'
|
commit object. It uses what is called an 'extended SHA-1'
|
||||||
syntax. Here are various ways to spell object names. The
|
syntax. Here are various ways to spell object names. The
|
||||||
ones listed near the end of this list name trees and
|
ones listed near the end of this list name trees and
|
||||||
blobs contained in a commit.
|
blobs contained in a commit.
|
||||||
|
|
||||||
'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
|
'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
|
||||||
The full SHA1 object name (40-byte hexadecimal string), or
|
The full SHA-1 object name (40-byte hexadecimal string), or
|
||||||
a leading substring that is unique within the repository.
|
a leading substring that is unique within the repository.
|
||||||
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
|
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
|
||||||
name the same commit object if there is no other object in
|
name the same commit object if there is no other object in
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
sha1-array API
|
sha1-array API
|
||||||
==============
|
==============
|
||||||
|
|
||||||
The sha1-array API provides storage and manipulation of sets of SHA1
|
The sha1-array API provides storage and manipulation of sets of SHA-1
|
||||||
identifiers. The emphasis is on storage and processing efficiency,
|
identifiers. The emphasis is on storage and processing efficiency,
|
||||||
making them suitable for large lists. Note that the ordering of items is
|
making them suitable for large lists. Note that the ordering of items is
|
||||||
not preserved over some operations.
|
not preserved over some operations.
|
||||||
|
@ -11,7 +11,7 @@ Data Structures
|
||||||
|
|
||||||
`struct sha1_array`::
|
`struct sha1_array`::
|
||||||
|
|
||||||
A single array of SHA1 hashes. This should be initialized by
|
A single array of SHA-1 hashes. This should be initialized by
|
||||||
assignment from `SHA1_ARRAY_INIT`. The `sha1` member contains
|
assignment from `SHA1_ARRAY_INIT`. The `sha1` member contains
|
||||||
the actual data. The `nr` member contains the number of items in
|
the actual data. The `nr` member contains the number of items in
|
||||||
the set. The `alloc` and `sorted` members are used internally,
|
the set. The `alloc` and `sorted` members are used internally,
|
||||||
|
|
|
@ -34,7 +34,7 @@ Git pack format
|
||||||
Observation: length of each object is encoded in a variable
|
Observation: length of each object is encoded in a variable
|
||||||
length format and is not constrained to 32-bit or anything.
|
length format and is not constrained to 32-bit or anything.
|
||||||
|
|
||||||
- The trailer records 20-byte SHA1 checksum of all of the above.
|
- The trailer records 20-byte SHA-1 checksum of all of the above.
|
||||||
|
|
||||||
== Original (version 1) pack-*.idx files have the following format:
|
== Original (version 1) pack-*.idx files have the following format:
|
||||||
|
|
||||||
|
@ -55,10 +55,10 @@ Git pack format
|
||||||
|
|
||||||
- The file is concluded with a trailer:
|
- The file is concluded with a trailer:
|
||||||
|
|
||||||
A copy of the 20-byte SHA1 checksum at the end of
|
A copy of the 20-byte SHA-1 checksum at the end of
|
||||||
corresponding packfile.
|
corresponding packfile.
|
||||||
|
|
||||||
20-byte SHA1-checksum of all of the above.
|
20-byte SHA-1-checksum of all of the above.
|
||||||
|
|
||||||
Pack Idx file:
|
Pack Idx file:
|
||||||
|
|
||||||
|
@ -106,7 +106,7 @@ Pack file entry: <+
|
||||||
If it is not DELTA, then deflated bytes (the size above
|
If it is not DELTA, then deflated bytes (the size above
|
||||||
is the size before compression).
|
is the size before compression).
|
||||||
If it is REF_DELTA, then
|
If it is REF_DELTA, then
|
||||||
20-byte base object name SHA1 (the size above is the
|
20-byte base object name SHA-1 (the size above is the
|
||||||
size of the delta data that follows).
|
size of the delta data that follows).
|
||||||
delta data, deflated.
|
delta data, deflated.
|
||||||
If it is OFS_DELTA, then
|
If it is OFS_DELTA, then
|
||||||
|
@ -135,7 +135,7 @@ Pack file entry: <+
|
||||||
|
|
||||||
- A 256-entry fan-out table just like v1.
|
- A 256-entry fan-out table just like v1.
|
||||||
|
|
||||||
- A table of sorted 20-byte SHA1 object names. These are
|
- A table of sorted 20-byte SHA-1 object names. These are
|
||||||
packed together without offset values to reduce the cache
|
packed together without offset values to reduce the cache
|
||||||
footprint of the binary search for a specific object name.
|
footprint of the binary search for a specific object name.
|
||||||
|
|
||||||
|
@ -156,7 +156,7 @@ Pack file entry: <+
|
||||||
|
|
||||||
- The same trailer as a v1 pack file:
|
- The same trailer as a v1 pack file:
|
||||||
|
|
||||||
A copy of the 20-byte SHA1 checksum at the end of
|
A copy of the 20-byte SHA-1 checksum at the end of
|
||||||
corresponding packfile.
|
corresponding packfile.
|
||||||
|
|
||||||
20-byte SHA1-checksum of all of the above.
|
20-byte SHA-1-checksum of all of the above.
|
||||||
|
|
|
@ -89,7 +89,7 @@ Ah, grasshopper! And thus the enlightenment begins anew.
|
||||||
|
|
||||||
<linus> The "magic" is actually in theory totally arbitrary.
|
<linus> The "magic" is actually in theory totally arbitrary.
|
||||||
ANY order will give you a working pack, but no, it's not
|
ANY order will give you a working pack, but no, it's not
|
||||||
ordered by SHA1.
|
ordered by SHA-1.
|
||||||
|
|
||||||
Before talking about the ordering for the sliding delta
|
Before talking about the ordering for the sliding delta
|
||||||
window, let's talk about the recency order. That's more
|
window, let's talk about the recency order. That's more
|
||||||
|
|
|
@ -8,7 +8,7 @@ repo, and therefore grafts are introduced pretending that
|
||||||
these commits have no parents.
|
these commits have no parents.
|
||||||
*********************************************************
|
*********************************************************
|
||||||
|
|
||||||
The basic idea is to write the SHA1s of shallow commits into
|
The basic idea is to write the SHA-1s of shallow commits into
|
||||||
$GIT_DIR/shallow, and handle its contents like the contents
|
$GIT_DIR/shallow, and handle its contents like the contents
|
||||||
of $GIT_DIR/info/grafts (with the difference that shallow
|
of $GIT_DIR/info/grafts (with the difference that shallow
|
||||||
cannot contain parent information).
|
cannot contain parent information).
|
||||||
|
@ -18,7 +18,7 @@ even the config, since the user should not touch that file
|
||||||
at all (even throughout development of the shallow clone, it
|
at all (even throughout development of the shallow clone, it
|
||||||
was never manually edited!).
|
was never manually edited!).
|
||||||
|
|
||||||
Each line contains exactly one SHA1. When read, a commit_graft
|
Each line contains exactly one SHA-1. When read, a commit_graft
|
||||||
will be constructed, which has nr_parent < 0 to make it easier
|
will be constructed, which has nr_parent < 0 to make it easier
|
||||||
to discern from user provided grafts.
|
to discern from user provided grafts.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue