Objects

Git's basest level is a storage and naming system for things Git calls -“objects.” These objects hold the bulk of the data about files and projects -tracked by Git: file contents, directory trees, commits, and so on. Every -object is identified by a SHA-1 hash, which is derived from its contents.

SHA-1 hashes are obnoxiously long, so Git allows you to substitue any unique -prefix of a SHA-1 hash, so long as it's at least four characters long. If the -hash 0b43b9e3e64793f5a222a644ed5ab074d8fa1024 is present in your repository, -then Git commands will understand 0b43, 0b43b9, and other patterns to all -refer to the same object, so long as no other object has the same SHA-1 -prefix.

Blobs

The contents of every file that's ever been stored in a Git repository are -stored as blob objects. These objects are very simple: they contain the file -contents, byte for byte.

Trees

File contents (and trees, and Other Things we'll get to later) are tied -together into a directory structure by tree objects. These objects contain a -list of records, with one child per record. Each record contains a permissions -field corresponding to the POSIX permissions mask of the object, a type, a -SHA-1 for another object, and a name.

A directory containing only files might be represented as the tree

100644 blob 511542ad6c97b28d720c697f7535897195de3318    config.md
-100644 blob 801ddd5ae10d6282bbf36ccefdd0b052972aa8e2    integrate.md
-100644 blob 61d28155862607c3d5d049e18c5a6903dba1f85e    scratch.md
-100644 blob d7a79c144c22775239600b332bfa120775bab341    survival.md
-

while a directory with subdirectories would also have some tree children:

040000 tree f57ef2457a551b193779e21a50fb380880574f43    12factor
-040000 tree 844697ce99e1ef962657ce7132460ad7a38b7584    authnz
-100644 blob 54795f9b774547d554f5068985bbc6df7b128832    cool-urls-can-change.md
-040000 tree fc3f39eb5d1a655374385870b8be56b202be7dd8    dev
-040000 tree 22cbfb2c1d7b07432ea7706c36b0d6295563c69c    devops
-040000 tree 0b3e63b4f32c0c3acfbcf6ba28d54af4c2f0d594    git
-040000 tree 5914fdcbd34e00e23e52ba8e8bdeba0902941d3f    java
-040000 tree 346f71a637a4f8933dc754fef02515a8809369c4    mysql
-100644 blob b70520badbb8de6a74b84788a7fefe64a432c56d    packaging-ideas.md
-040000 tree 73ed6572345a368d20271ec5a3ffc2464ac8d270    people
-

Commits

Blobs and trees are sufficient to store arbitrary directory trees in Git, and -you could use them that way, but Git is mostly used as a revision-tracking -system. Revisions and their history are represented by commit objects, which contain:

* The SHA-1 hash of the root `tree` object of the commit,
-* Zero or more SHA-1 hashes for parent commits,
-* The name and email address of the commit's “author,”
-* The name and email address of the commit's “committer,”
-* Timestamps representing when the commit was authored and committed, and
-* A commit message.
-

Commit objects' parent references form a directed acyclic graph; the subgraph -reachable from a specific commit is that commit's history.

When working with Git's user interface, commit parents are given in a -predictable order determined by the git checkout and git merge commands.

Anonymity

There's a general theme to Git's object types: no object knows its own name. -Every object only has a name in the context of some containing object, or in -the context of Git's refs mechanism, which I'll get to -shortly. This means that the same blob object can be reused for multiple -files (or, more probably, the same file in multiple commits), if they happen -to have the same contents.

This also applies to tag objects, even though their role is part of a system -for providing stable, meaningful names for commits.

Examining objects

-
git cat-file <type> <sha1>: decodes the object <sha1> and prints its - contents to stdout. This prints the object's contents in their raw form, - which is less than useful for tree objects.
-
-
git cat-file -p <sha1>: decodes the object <sha1> and pretty-prints it. - This pretty-printing stays close to the underlying disk format; it's most - useful for decoding tree objects.
-
-
git show <sha1>: decodes the object <sha1> and formats its contents to - stdout. For blobs, this is identical to what git cat-file blob would do, - but for trees, commits, and tags, the output is reformated to be more - readable.
-

Storage

Objects are stored in two places in Git: as “loose objects,” and in “pack -files.” Newly-created objects are initially loose objects, for ease of -manipulation; transferring objects to another repository or running certain -administrative commands can cause them to be placed in pack files for faster -transfer and for smaller storage.

Loose objects are stored directly on the filesystem, in the Git repository's -objects directory. Git takes a two-character prefix off of each object's -SHA-1 hash, and uses that to pick a subdirectory of objects to store the -object in. The remainder of the hash forms the filename. Loose objects are -compressed with zlib, to conserve space, but the resulting directory tree can -still be quite large.

Packed objects are stored together in packed files, which live in the -repository's objects/pack directory. These packed files are both compressed -and delta-encoded, allowing groups of similar objects to be stored very -compactly.

- - - -

- - -comments powered by Disqus -

- - - - - -