Architecting Version Control with Git's Content-Addressable Storage

The Problem: Ensuring Immutable History at Scale

Traditional version control systems often track changes as a series of deltas (differences) between files. This approach creates a dependency chain: to reconstruct a file at version 100, the system must apply 99 sequential patches. If one patch is corrupted, the entire subsequent history is lost. Git solves this by treating the repository not as a list of changes, but as a Content-Addressable Storage (CAS) system combined with a Directed Acyclic Graph (DAG).

Core Requirements for a Versioning Store

To maintain a reliable history, a versioning system must satisfy three primary constraints:

• Integrity: The system must detect if a file was altered by disk failure or malicious intent.
• Efficiency: Identical files across different versions or branches should not occupy double the space.
• Non-linearity: The system must support diverging paths (branching) and converging paths (merging) without duplicating the entire project state.

The Smallest Suitable Design: Blobs, Trees, and Commits

Git implements these requirements using three primary object types stored in the .git/objects directory. Every object is identified by a hash of its contents (historically SHA-1, with SHA-256 available in newer versions), meaning the address of the data is the data itself.

Object Type	Responsibility	Reference Content
Blob (Binary Large Object)	Stores file data	The raw bytes of the file content.
Tree	Stores directory structure	Pointers (hashes) to blobs and other sub-trees.
Commit	Stores snapshot metadata	Pointer to a root tree, author, timestamp, and parent commit(s).

This creates a DAG where a commit points to a tree, which points to blobs. If a file does not change between two commits, both commits simply point to the same blob hash, eliminating redundancy.

Trust and Data Boundaries

The boundary of trust in Git is the local .git directory. Because every object is hashed, Git does not trust the filename or the timestamp provided by the OS; it trusts the hash. If a single bit flips in a blob, the hash changes, and the pointer from the tree object becomes invalid, immediately signaling corruption.

Operational Checks and Verification

To verify that the DAG is intact and no objects are missing or corrupted, use the fsck (file system check) tool. This should be run as a user with read permissions to the .git directory.

# Run this from the root of your local repository
git fsck --full

Expected Result: A clean run returns no output or a message stating that the repository is healthy. If corruption exists, Git will report "missing" or "dangling" objects.

To manually trace the relationship between these objects, you can use the cat-file command. This allows you to move from the high-level commit down to the raw data:

# 1. View commit metadata (find the 'tree' hash)
git cat-file -p [commit-hash]

# 2. View the tree contents (find the 'blob' hash for a specific file)
git cat-file -p [tree-hash]

# 3. View the actual file content
git cat-file -p [blob-hash]

Failure Modes and Design Limitations

Despite its robustness, the CAS architecture has specific failure modes:

• Hash Collisions: While rare, two different files producing the same SHA-1 hash would cause Git to overwrite one with the other. This is why Git is transitioning toward SHA-256 for high-security environments.
• Binary Bloat: Because Git is optimized for text, large binary files (images, compiled binaries) that change slightly result in entirely new blobs. This causes the .git directory to grow exponentially.
• Interrupted Writes: If a system crashes while writing an object to disk, a "corrupt object" error may occur during the next fsck or checkout.

Conditions for Design Change

The current DAG/CAS design is highly efficient for source code. However, the architecture would require a fundamental shift if the following occurred:

1. Extreme Scale: If a repository reached billions of objects, the flat indexing of the .git/objects directory would cause OS-level filesystem slowdowns (mitigated currently by Git's "fan-out" directory structure).
2. Requirement for Mutable History: If the business requirement shifted to allow the modification of historical data without changing the hash (impossible by design), the CAS model would have to be replaced with a traditional database.