objects). There are currently four different object types: "blob",
"tree", "commit" and "tag".
objects). There are currently four different object types: "blob",
"tree", "commit" and "tag".
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.
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.
Regardless of object type, all objects share the following
characteristics: they are all deflated with zlib, and have a header
Regardless of object type, all objects share the following
characteristics: they are all deflated with zlib, and have a header
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
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
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
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
size> + <byte\0> + <binary object data>.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
size> + <byte\0> + <binary object data>.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
of all objects, and verifies their internal consistency (in addition
to just verifying their superficial consistency through the hash).
of all objects, and verifies their internal consistency (in addition
to just verifying their superficial consistency through the hash).
directory tree, and renaming a file does not change the object that
file is associated with in any way.
directory tree, and renaming a file does not change the object that
file is associated with in any way.
-A blob is typically created when link:git-update-cache.html[git-update-cache]
-is run, and its data can be accessed by link:git-cat-file.html[git-cat-file].
+A blob is typically created when gitlink:git-update-index[1]
+is run, and its data can be accessed by gitlink:git-cat-file[1].
noticing that the blob stayed the same. However, renames with data
changes need a smarter "diff" implementation.
noticing that the blob stayed the same. However, renames with data
changes need a smarter "diff" implementation.
-A tree is created with link:git-write-tree.html[git-write-tree] and
-its data can be accessed by link:git-ls-tree.html[git-ls-tree].
-Two trees can be compared with link:git-diff-tree.html[git-diff-tree].
+A tree is created with gitlink:git-write-tree[1] and
+its data can be accessed by gitlink:git-ls-tree[1].
+Two trees can be compared with gitlink:git-diff-tree[1].
-A commit is created with link:git-commit-tree.html[git-commit-tree] and
-its data can be accessed by link:git-cat-file.html[git-cat-file].
+A commit is created with gitlink:git-commit-tree[1] and
+its data can be accessed by gitlink:git-cat-file[1].
-A tag is created with link:git-mktag.html[git-mktag],
-its data can be accessed by link:git-cat-file.html[git-cat-file],
+A tag is created with gitlink:git-mktag[1],
+its data can be accessed by gitlink:git-cat-file[1],
generally update the index information by just specifying the filename
you want to update, like so:
generally update the index information by just specifying the filename
you want to update, like so:
but to avoid common mistakes with filename globbing etc, the command
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
but to avoid common mistakes with filename globbing etc, the command
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
should use the `--remove` and `--add` flags respectively.
NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
should use the `--remove` and `--add` flags respectively.
NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
files. This is not a very common operation, since normally you'd just
keep your files updated, and rather than write to your working
directory, you'd tell the index files about the changes in your
files. This is not a very common operation, since normally you'd just
keep your files updated, and rather than write to your working
directory, you'd tell the index files about the changes in your
However, if you decide to jump to a new version, or check out somebody
else's version, or just restore a previous tree, you'd populate your
index file with read-tree, and then you need to check out the result
with
However, if you decide to jump to a new version, or check out somebody
else's version, or just restore a previous tree, you'd populate your
index file with read-tree, and then you need to check out the result
with
if you have an old version of the tree already checked out, you will
need to use the "-f" flag ('before' the "-a" flag or the filename) to
'force' the checkout.
if you have an old version of the tree already checked out, you will
need to use the "-f" flag ('before' the "-a" flag or the filename) to
'force' the checkout.
that commit, and you should save it away for later use. Normally,
you'd commit a new `HEAD` state, and while git doesn't care where you
save the note about that state, in practice we tend to just write the
that commit, and you should save it away for later use. Normally,
you'd commit a new `HEAD` state, and while git doesn't care where you
save the note about that state, in practice we tend to just write the
-result to the file `.git/HEAD`, so that we can always see what the
-last committed state was.
+result to the file pointed at by `.git/HEAD`, so that we can always see
+what the last committed state was.
+
+Here is an ASCII art by Jon Loeliger that illustrates how
+various pieces fit together.
+
+------------
+
+ commit-tree
+ commit obj
+ +----+
+ | |
+ | |
+ V V
+ +-----------+
+ | Object DB |
+ | Backing |
+ | Store |
+ +-----------+
+ ^
+ write-tree | |
+ tree obj | |
+ | | read-tree
+ | | tree obj
+ V
+ +-----------+
+ | Index |
+ | "cache" |
+ +-----------+
+ update-index ^
+ blob obj | |
+ | |
+ checkout-index -u | | checkout-index
+ stat | | blob obj
+ V
+ +-----------+
+ | Working |
+ | Directory |
+ +-----------+
+
+------------
+
6) Examining the data
~~~~~~~~~~~~~~~~~~~~~
You can examine the data represented in the object database and the
index with various helper tools. For every object, you can use
6) Examining the data
~~~~~~~~~~~~~~~~~~~~~
You can examine the data represented in the object database and the
index with various helper tools. For every object, you can use
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
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.
that path tells git to mark the path resolved.
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`
that path tells git to mark the path resolved.
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-cache` program that extracts the
-stages to temporary files and calls a `merge` script on it
+for this. There is `git-merge-index` program that extracts the
+stages to temporary files and calls a "merge" script on it: