The Object Database: Git Is a Content-Addressed Store

Git has a reputation for an inconsistent command line, and it is deserved. The data model underneath is small, regular, and worth learning first, because every confusing command becomes obvious once you know what it manipulates.

Git is a content-addressed key-value store. You hand it content, it returns a hash; you hand it the hash, it returns the content. The key is computed from the value, so it is not chosen and cannot be changed independently.

Everything is built from four object types stored that way, and there are no others. Not a diff, not a changeset, not a patch: those are computed on demand for display, and the storage is whole snapshots.

That is the first surprise for people arriving from other version control systems. Git does not store what changed. It stores what everything was, at each commit, and derives the differences when asked.

The rest of the model follows from that choice, including the properties that make branching cheap.

The hash is not of the file's bytes. It is of a small header plus the bytes, and computing it manually is the fastest way to make the model concrete.

The format is the object type, a space, the content length in bytes, a null byte, then the content.

$ printf 'hello\n' > a.txt
$ git hash-object a.txt
ce013625030ba8dba906f756967f9e9ca394464a

$ printf 'blob 6\0hello\n' | sha1sum
ce013625030ba8dba906f756967f9e9ca394464a  -

The same hash, computed with a standard tool and no Git involved. The content is six bytes, hello plus a newline, and the header says so.

Two consequences follow immediately.

Identical content is stored once. The same file in fifty directories, or unchanged across a thousand commits, hashes identically and occupies one object. Snapshot-per-commit storage is affordable because the snapshots share almost everything.

The name is a checksum. Retrieving an object and hashing it again verifies it, so corruption is detectable rather than silent.

Blob. File contents. Nothing else: no filename, no permissions, no timestamp. A blob is bytes, which is why renaming a file creates no new blob.

Tree. A directory. It lists entries, each with a mode, a type, a hash and a name, and it can point at blobs or at other trees.

100644 blob ce013625030ba8dba906f756967f9e9ca394464a    a.txt

That is a real tree listing. The filename lives here, in the tree, rather than in the blob, which is exactly why identical content under different names shares one object.

Commit. A pointer to one tree, plus zero or more parent commits, an author, a committer, and a message.

Tag. A named pointer to an object with its own message and author, used for annotated tags.

That is the whole vocabulary. A repository is these four types in a store keyed by hash, and every Git command is a way of creating them, reading them, or moving pointers to them.

Notice what is absent: there is no object representing a change. A diff between two commits is computed by comparing their trees when you ask for it.

Reading a commit object directly settles several common misconceptions at once.

$ git cat-file -p HEAD
tree 2e81171448eb9f2ee3821e3d447aa6b2fe3ddba1
author T <t@e.com> 1785236627 +0200
committer T <t@e.com> 1785236627 +0200

first

That is the entire object. A few lines of text.

A commit points at one tree, which is the complete state of the project at that moment. Not a change: a full snapshot of every file.

Author and committer are separate fields, with separate timestamps. The author wrote the change; the committer applied it. They differ when a patch is applied by a maintainer or when a commit is rebased, which is why rebasing preserves authorship while changing the committer.

The parent is absent here because this is the first commit. Later commits list one parent, merges list two or more, and that field is the only thing that gives history its shape.

A commit with no parents is a root; the parent links are what make the whole thing a graph rather than a pile.

Every arrow is a hash, and every hash is computed from the content of the thing it points at. That makes the whole structure a Merkle tree, the same construction used in the lesson Applied Modern Cryptography and in distributed ledgers.

The property that buys is significant. A commit's hash depends on its tree, which depends on every blob and subtree beneath it, and on its parent, which depends on all of history before it.

So changing anything, anywhere in the past, changes that object's hash, which changes its parent's, and so on to every descendant. You cannot alter history without every subsequent commit hash changing.

That is why comparing one commit hash is enough to verify an entire repository state, and why rewriting shared history is visible rather than sneaky: the commits after the rewrite are different objects with different names.

The right-hand branch is the sharing. The parent's tree points at the same blobs for every unchanged file, so a commit touching one file in a large repository creates one new blob, a few new trees along its path, and one new commit.

Storing a full snapshot per commit sounds wasteful, and the objection dissolves once the sharing is clear. Two mechanisms handle it.

Structural sharing. Unchanged files are the same blob, referenced again. A thousand-commit history of a project where each commit touches one file stores roughly one project's worth of blobs plus a thousand small deltas' worth of new ones.

Packfiles. Loose objects are individually compressed, and periodically Git repacks them into a packfile that stores similar objects as deltas against each other. This is a storage optimisation applied after the fact, not part of the model: the object graph is still snapshots, and the packfile is how they are written to disk.

The ordering matters conceptually. Systems that store diffs as their model must reconstruct a version by replaying a chain, so checking out an old revision costs more the older it is. Git looks up a tree and reads it, so accessing any commit costs the same.

That is what makes branching and switching cheap, and cheap branching is the reason Git's workflow looks the way it does. It is downstream of the storage decision.

The index, or staging area, confuses people because it seems like an arbitrary extra step. Understanding it as a tree under construction removes the confusion.

Git has three states for content, and they are three different places.

Working directory. Ordinary files on disk. Git watches them and stores nothing of them.

Index. A file at .git/index holding the tree that the next commit will use. git add writes a blob into the object database and records its hash in the index.

Object database. The permanent store.

The important detail is that git add already creates the blob. The content is written to the object database at that moment, not at commit time. Committing then builds tree objects from the index and creates a commit pointing at the root tree.

That explains a fact people find surprising: content added and then overwritten in the working directory is still recoverable, because the blob exists. It is unreferenced rather than absent, and git fsck --lost-found will find it until garbage collection runs.

The index exists so that what you commit is chosen explicitly rather than being whatever the disk happened to contain, which is what makes partial staging possible.

The third row is the one with security weight. A repository verified at one commit hash is verified in its entirety, and signed tags extend that to identity: signing one hash attests to all of history reachable from it.

One honest caveat. The hash function was SHA-1, and a practical collision was demonstrated in 2017. Git added hardened collision detection to its SHA-1 implementation and has an experimental SHA-256 object format, and the transition is ongoing rather than complete. The property is tamper-evident in practice; treating it as cryptographic proof against a determined adversary requires knowing which hash your repository uses.

What the model does not yet explain is how anyone finds a commit. Hashes are not memorable, and nothing so far names anything. That is refs, and it is the next lesson.