H0llyW00dzZ/git
H0llyW00dzZ/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2025-03-30 19:50:22 +00:00
Code Releases Activity

user-manual: reorder commit, blob, tree discussion

Browse Source 
The bottom-up blog, tree, commit order makes sense unless you want to
give explicit examples--it's easier to discover objects to examine if
you go in the other order....,

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
This commit is contained in:
J. Bruce Fields 2007-08-31 23:26:38 -04:00
parent 1c097891e4
commit 513d419c59
1 changed files with 41 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

82
Documentation/user-manual.txt
View File

@ -2766,27 +2766,32 @@ signature.
The object types in some more detail: The object types in some more detail:
[[blob-object]] [[commit-object]]
Blob Object Commit Object
~~~~~~~~~~~ ~~~~~~~~~~~~~
A "blob" object is nothing but a binary blob of data, and doesn't The "commit" object is an object that introduces the notion of
refer to anything else. There is no signature or any other history into the picture. In contrast to the other objects, it
verification of the data, so while the object is consistent (it 'is' doesn't just describe the physical state of a tree, it describes how
indexed by its sha1 hash, so the data itself is certainly correct), it we got there, and why.
has absolutely no other attributes. No name associations, no
permissions. It is purely a blob of data (i.e. normally "file
contents").
In particular, since the blob is entirely defined by its data, if two A "commit" is defined by the tree-object that it results in, the
files in a directory tree (or in multiple different versions of the parent commits (zero, one or more) that led up to that point, and a
repository) have the same contents, they will share the same blob comment on what happened. Again, a commit is not trusted per se:
object. The object is totally independent of its location in the the contents are well-defined and "safe" due to the cryptographically
directory tree, and renaming a file does not change the object that strong signatures at all levels, but there is no reason to believe
file is associated with in any way. that the tree is "good" or that the merge information makes sense.
The parents do not have to actually have any relationship with the
result, for example.
A blob is typically created when gitlink:git-update-index[1] Note on commits: unlike some SCM's, commits do not contain
is run, and its data can be accessed by gitlink:git-cat-file[1]. rename information or file mode change information. All of that is
implicit in the trees involved (the result tree, and the result trees
of the parents), and describing that makes no sense in this idiotic
file manager.
A commit is created with gitlink:git-commit-tree[1] and
its data can be accessed by gitlink:git-cat-file[1].
[[tree-object]] [[tree-object]]
Tree Object Tree Object
@ -2830,32 +2835,27 @@ A tree is created with gitlink:git-write-tree[1] and
its data can be accessed by gitlink:git-ls-tree[1]. its data can be accessed by gitlink:git-ls-tree[1].
Two trees can be compared with gitlink:git-diff-tree[1]. Two trees can be compared with gitlink:git-diff-tree[1].
[[commit-object]] [[blob-object]]
Commit Object Blob Object
~~~~~~~~~~~~~ ~~~~~~~~~~~
The "commit" object is an object that introduces the notion of A "blob" object is nothing but a binary blob of data, and doesn't
history into the picture. In contrast to the other objects, it refer to anything else. There is no signature or any other
doesn't just describe the physical state of a tree, it describes how verification of the data, so while the object is consistent (it 'is'
we got there, and why. indexed by its sha1 hash, so the data itself is certainly correct), it
has absolutely no other attributes. No name associations, no
permissions. It is purely a blob of data (i.e. normally "file
contents").
A "commit" is defined by the tree-object that it results in, the In particular, since the blob is entirely defined by its data, if two
parent commits (zero, one or more) that led up to that point, and a files in a directory tree (or in multiple different versions of the
comment on what happened. Again, a commit is not trusted per se: repository) have the same contents, they will share the same blob
the contents are well-defined and "safe" due to the cryptographically object. The object is totally independent of its location in the
strong signatures at all levels, but there is no reason to believe directory tree, and renaming a file does not change the object that
that the tree is "good" or that the merge information makes sense. file is associated with in any way.
The parents do not have to actually have any relationship with the
result, for example.
Note on commits: unlike some SCM's, commits do not contain A blob is typically created when gitlink:git-update-index[1]
rename information or file mode change information. All of that is is run, and its data can be accessed by gitlink:git-cat-file[1].
implicit in the trees involved (the result tree, and the result trees
of the parents), and describing that makes no sense in this idiotic
file manager.
A commit is created with gitlink:git-commit-tree[1] and
its data can be accessed by gitlink:git-cat-file[1].
[[trust]] [[trust]]
Trust Trust