How Git Works Internally: Blobs, Trees, Commits, and the Directed Acyclic Graph (DAG)

Executive Summary & Key Takeaways

Imagine a high-security international museum archive. Instead of cataloging rare artifacts by the room or shelf where they currently sit, the head curator places every item into an airtight, transparent glass container. The curator then weighs and optically scans the object to compute a tamper-proof cryptographic wax seal that is stamped onto the container lid. If an assistant changes even a single letter in an ancient manuscript, the physical seal value alters completely, forcing the creation of a distinct container. The museum directory does not store manuscripts directly; it maintains index cards that pair human-readable labels with these permanent container seals. When curators curate a new seasonal gallery, they do not duplicate the artifacts; they draft a signed exhibition ledger citing the master index card and referencing the ledger stamp of the previous exhibition on which it was founded.

This physical mechanism mirrors the low-level architecture of Git. Beneath its familiar command-line interface, Git operates as a content-addressable key-value datastore layered under an immutable Directed Acyclic Graph (DAG). Git does not track file deltas across branches in the manner of legacy Version Control Systems such as CVS or Subversion. Instead, Git models repository history through four primary immutable primitives: blobs, trees, commits, and annotated tags. These primitives reside within the .git/objects/ filesystem hierarchy. Every object is keyed strictly by the cryptographic hash of its payload and header. By separating pure file payloads from file names and execution modes, Git achieves instantaneous data deduplication, cryptographically verifiable history, and near-zero-overhead branch manipulation.

• Content-Addressable Storage (CAS): Repository objects are referenced solely by their cryptographic digest (SHA-1 or SHA-256), decoupling an object's physical identity from its transient filesystem path.
• Orthogonal Object Primitives: Blobs encapsulate raw byte streams without metadata; trees record directory hierarchies and file permission modes; commits bind a root tree to historical parent lineages and author identities.
• Cryptographic DAG Invariants: Commit graphs move backward in time. Children reference their ancestors via immutable hashes, making retrospective history modification mathematically impossible without altering every descendant hash.
• Two-Tier Storage Architecture: The engine balances high-speed write concurrency and high-density long-term storage by transitioning from loose objects (segmented disk allocations) to packfiles (contiguous binary blocks with sliding-window delta compression).
• Entropy-Driven Processing Divergence: Packfile generation and sliding-window delta searches sustain throughputs exceeding 100 MB/s on low-entropy source code, but collapse to 5–10 MB/s when processing high-entropy pre-compressed binaries due to repeated delta match failures.

1. Architectural Foundations & Mechanics

To inspect Git at the systems level, one must strip away the high-level porcelain commands—such as git add, git commit, and git checkout—and examine the plumbing layer that governs the operating system interface. At rest on a POSIX filesystem, a Git repository is encapsulated within the hidden .git/ directory. The core engine coordinates three distinct computational spaces: the working tree (the uncompressed physical directory structure on disk), the index (the binary staging register), and the object database (the content-addressable key-value store residing in .git/objects/).

The Universal Object Envelope and Content Addressability

Every piece of persisted data in Git—whether a 5-byte configuration snippet, an arbitrary binary asset, a directory listing, or a signed release manifest—is serialized inside a uniform envelope before being compressed and written to storage. This envelope establishes a standardized byte framing:

[object-type-ascii] [space] [size-in-bytes-ascii] [\0] [binary-payload]

The object type is an ASCII string matching one of the core primitives: blob, tree, commit, or tag. The size represents the length in bytes of the uncompressed payload encoded as human-readable ASCII digits, followed immediately by a single null byte (0x00). The cryptographic identifier is computed by executing the hash algorithm across this entire composite envelope:

$\text{ObjectID} = \mathcal{H}(\text{type} \mathbin{\Vert} \text{" "} \mathbin{\Vert} \text{size} \mathbin{\Vert} \text{"\0"} \mathbin{\Vert} \text{payload})$

In standard repositories, $\mathcal{H}$ represents SHA-1, producing a 160-bit (20-byte) hash represented as 40 hexadecimal characters. Modern repositories initialized with --object-format=sha256 compute a 256-bit (32-byte) digest represented as 64 hexadecimal characters. Once computed, the complete envelope is compressed via zlib DEFLATE at compression level 6 (configurable via core.compression) and persisted to disk.

To prevent local filesystems from suffering performance degradation when directory entries exceed several thousand files in a single inode directory block, Git shards the object store. The first 2 hexadecimal characters of the hash designate a subdirectory inside .git/objects/, while the remaining 38 (or 62) characters define the filename. For instance, an object with hash e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 is located at:

.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391

The Four Core Object Primitives

The entire expressive power of Git emerges from the structural composition of four distinct, immutable object types.

1. Blobs (Binary Large Objects)

A blob represents pure, unadorned content. When Git reads a file from the working directory, it writes the exact file contents into a blob object. A blob does not record the original filename, the directory location, the file modification timestamp, or the executable permission bits.

Because the identity of a blob depends exclusively on its content bytes, identical files across disparate subdirectories share the exact same blob hash. If an engineer duplicates a 50-megabyte static dataset into ten different directories across a monorepo, Git writes exactly one 50-megabyte compressed blob into the object database. The directory associations are delegated entirely to trees.

2. Trees

A tree corresponds directly to a filesystem directory entry. It provides the structural context that blobs lack, binding human-readable path strings, POSIX file permissions, and object hashes together into an ordered binary manifest.

The uncompressed payload of a tree object consists of a sequential, non-padded series of binary records. Each record adheres to the following byte layout:

[posix-mode-octal-ascii] [space] [path-string] [\0] [binary-hash-bytes]

The POSIX file mode is written as octal ASCII characters without leading zeros. Valid modes include 100644 for standard non-executable files, 100755 for executable binaries or scripts, 120000 for symbolic links (whose target path is preserved within a referenced blob), 040000 for a directory (pointing to a subordinate tree object), and 160000 for submodules (gitlinks pointing directly to a foreign commit hash).

Crucially, the binary hash appended to each entry is not the 40-character ASCII representation, but the raw 20-byte (for SHA-1) or 32-byte (for SHA-256) binary digest. Entries within a tree are deterministically sorted: filenames are sorted byte-for-byte in ascending order, with subtrees evaluated as if their path string concluded with a trailing slash (/). This strict canonical ordering ensures that identical directory states always yield byte-identical tree hashes regardless of which operating system or locale built the tree.

3. Commits

A commit object models a permanent, immutable point-in-time snapshot of the overall project state. While trees capture directory hierarchies, commit objects wrap a single root tree in historical lineage and provenance metadata.

The commit payload is a structured UTF-8 text document containing explicit header fields followed by an author-supplied log message:

tree 7f8a9c21b3e456d89a0123456789abcdef012345
parent 3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
author Linus Torvalds <torvalds@linux-foundation.org> 1112911993 -0700
committer Linus Torvalds <torvalds@linux-foundation.org> 1112911993 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 [arbitrary base64 signature payload]
 -----END PGP SIGNATURE-----

Initial operational commit for the project architecture.

The commit schema enforces strict structural semantics:

• tree: Exactly one 40-character or 64-character hexadecimal reference to the root directory tree object representing the complete snapshot.
• parent: Zero, one, or more hexadecimal parent commit references. A root commit (the initial repository state) has zero parent lines. Standard commits possess exactly one parent. Merge commits contain two parent references (the target branch and the branch being merged). Octopus merges contain three or more parent pointers.
• author: The developer who wrote the code, represented as a name, an email address encased in angle brackets, a 64-bit integer Unix timestamp, and a timezone offset from UTC.
• committer: The entity who applied the commit to the graph (for instance, an engineer applying an email patch or a continuous integration bot rebasing a branch).
• gpgsig: An optional cryptographic signature verifying that the commit payload was authenticated by the committer's private key.

4. Annotated Tags

Unlike lightweight tags (which are merely plain text reference files in .git/refs/tags/ pointing directly to a commit), an annotated tag is an independent, first-class object within .git/objects/. It contains a target object hash, a target type indicator (frequently commit, though Git permits tagging arbitrary trees or blobs), the tag name, tagger identity credentials with timestamps, an optional GPG signature, and an arbitrary descriptive message.

The Directed Acyclic Graph (DAG) Topology

The structural relationship between commits establishes an immutable Directed Acyclic Graph. The orientation of this graph is counter-intuitive to many software engineers: edges point backward in time, from children to parents.

When a developer issues a new commit, the new commit object records the cryptographic hash of the current commit as its parent. The parent commit, having been written previously, has no awareness of its future descendants. Because an object's identifier is cryptographically derived from its payload—and because that payload includes the parent hash—it is impossible to introduce a directed cycle into the graph. To create a cycle where Commit A points to Commit B and Commit B points to Commit A, one would have to compute a cryptographic preimage collision against SHA-1 or SHA-256.

Branches in Git are not heavy, stateful containers. A branch is simply a named, movable pointer stored as a 41-byte text file (40 hex characters plus a newline) inside .git/refs/heads/. When an engineer commits on main, Git creates the new commit object pointing to the old commit, and then updates the single file .git/refs/heads/main to store the newly generated commit hash. The symbolic reference HEAD simply tracks which reference is currently checked out into the working directory (e.g., ref: refs/heads/main). A "detached HEAD" state occurs when HEAD stores a raw commit hash directly instead of pointing to a symbolic reference path.

The Staging Register: Mechanics of .git/index

The binary file located at .git/index serves as the intermediate coordination gate between the physical working tree and the immutable DAG. Rather than recursively walking the disk directory structure during every invocation of git status, Git relies on the index as an in-memory cache of working-tree file states.

The index file format (DIRC) begins with a 12-byte header consisting of a 4-byte signature (DIRC), a 4-byte binary version number (commonly version 2, 3, or 4), and a 32-bit big-endian integer specifying the total number of index entries. Each file entry contains low-level POSIX filesystem stat cache data:

• ctime seconds and nanosecond fractions (8 bytes)
• mtime seconds and nanosecond fractions (8 bytes)
• Device identifier dev (4 bytes) and inode number ino (4 bytes)
• POSIX file mode (4 bytes)
• User ID uid (4 bytes) and Group ID gid (4 bytes)
• Uncompressed file size on disk (4 bytes)
• The 20-byte or 32-byte object hash of the staged blob
• 16-bit bitfield flags (incorporating the staging merge stage, validity bits, and path string length)
• The null-terminated relative file path string

When an engineer runs git status, Git executes an lstat() system call on each path registered in the index. If the file's current mtime, ctime, and file_size on disk match the values recorded in the index, Git knows with mathematical certainty that the file content has not changed. It skips reading the file data entirely, bypassing disk I/O and hash calculations. If the stat cache diverges, Git re-hashes the file to verify whether the payload altered.

Furthermore, the index maintains an optimization known as the Cache-Tree extension. When a commit is generated, Git does not need to rebuild unchanged subdirectories from scratch. The Cache-Tree records previously calculated tree hashes for sub-paths within the index that contain no staged modifications, allowing sub-second commit execution even on codebases containing hundreds of thousands of files.

2. Mathematical Modeling & Resource Bounds

To rigorously architect large-scale source code management infrastructure, systems engineers must model the storage footprints, memory requirements, and computational bounds governing Git's internal operations.

Formalization of Graph Topology

Let a Git repository's history be formalized as a directed graph $G = (V, E)$, where the set of vertices $V$ is partitioned into four disjoint subsets:

$V = V_{\text{blob}} \cup V_{\text{tree}} \cup V_{\text{commit}} \cup V_{\text{tag}}$

The set of directed edges $E \subset V \times V$ represents cryptographic reference pointers. The graph obeys strict topological typing rules:

• $(u, v) \in E \text{ where } u \in V_{\text{commit}} \implies v \in V_{\text{commit}} \text{ (parent link) or } v \in V_{\text{tree}} \text{ (root tree)}$
• $(u, v) \in E \text{ where } u \in V_{\text{tree}} \implies v \in V_{\text{tree}} \text{ (sub-tree) or } v \in V_{\text{blob}} \text{ (file contents)}$
• $\forall u \in V_{\text{blob}}, \quad \text{out-degree}(u) = 0$

The commit graph $G_C = (V_{\text{commit}}, E_C)$ is an induced subgraph where $E_C = \{ (u, v) \in E \mid u, v \in V_{\text{commit}} \}$. The in-degree $\text{deg}^-(u)$ represents the number of parent commits referenced by commit $u$:

$\text{deg}^-(u) = \begin{cases} 0 & \text{Root commit} \\ 1 & \text{Linear commit} \\ 2 & \text{Dual-parent merge commit} \\ k \ge 3 & \text{Octopus merge commit} \end{cases}$

Because every commit node $u$ must incorporate the cryptographic hash of each parent $v \in \text{Parents}(u)$ into its immutable payload, the creation timestamp of $u$ strictly succeeds that of $v$. Under the cryptographic hardness of the preimage resistance of $\mathcal{H}$, the graph is guaranteed to be strictly acyclic:

$\nexists \text{ path } p = (v_1, v_2, \dots, v_m) \text{ such that } v_1 = v_m \text{ and } m > 1$

Storage Footprint: Loose Objects versus Packed Aggregates

The on-disk resource allocation for loose objects is heavily dominated by filesystem block allocation boundaries. Let $N_{\text{loose}}$ be the total count of loose objects, $S_i$ be the uncompressed byte size of object $i$, and $\mathcal{C}_{\text{zlib}}(S_i)$ be the compressed byte length after zlib DEFLATE. Filesystems allocate storage in discrete allocation units (clusters) of size $B_{\text{fs}}$, typically 4,096 bytes on ext4, XFS, and APFS.

The physical disk consumption $M_{\text{loose}}$ of the loose object store is given by:

$M_{\text{loose}} = \sum_{i=1}^{N_{\text{loose}}} \left( \left\lceil \frac{\mathcal{C}_{\text{zlib}}(S_i + S_{\text{hdr}, i})}{B_{\text{fs}}} \right\rceil \times B_{\text{fs}} \right) + N_{\text{loose}} \times I_{\text{inode}}$

Here, $S_{\text{hdr}, i}$ is the length of the envelope prefix (typically 15 to 30 bytes), and $I_{\text{inode}}$ represents the filesystem inode table footprint (commonly 256 to 512 bytes per allocated file). When a repository accumulates hundreds of thousands of small loose objects (e.g., 200-byte tree objects or minor code edits), the ceiling function causes severe internal block fragmentation, wasting up to 80% of actual physical disk allocation on slack space.

In contrast, Git packfiles consolidate millions of objects into a single contiguous binary block, completely eliminating filesystem cluster slack. The total packfile storage footprint $M_{\text{pack}}$ is defined as:

$M_{\text{pack}} = S_{\text{hdr}} + \sum_{j=1}^{N_{\text{base}}} \mathcal{C}_{\text{zlib}}(S_j) + \sum_{k=1}^{N_{\text{delta}}} \mathcal{C}_{\text{zlib}}\left(\Delta\left(S_k, S_{\text{base}(k)}\right)\right) + S_{\text{idx}}$

Where:

• $S_{\text{hdr}} = 12\text{ bytes}$ (the 4-byte PACK magic identifier, 4-byte version, and 4-byte object count).
• $N_{\text{base}}$ is the count of full, non-delta objects preserved in the packfile.
• $N_{\text{delta}}$ is the count of objects compressed against a base object using LibXDiff byte-level copy/insert instructions.
• $S_{\text{idx}}$ is the accompanying .idx v2 file size, formulated as $S_{\text{idx}} = 1024 + (N \times 28) + 40\text{ bytes}$ (incorporating the 256-entry primary fanout table, the SHA table, the 32-bit CRC table, the byte-offset array, and trailer checksums).

The Entropy Divergence in Delta Search Throughput

During packfile generation (invoked via git pack-objects or git gc), Git computes directed deltas across candidate objects. Git sorts all objects by type, filename hash, and uncompressed size, placing objects with identical names and similar sizes adjacent to one another within a sliding candidate window of size $W$ (default $W = 10$, controlled by pack.window) and depth limit $D$ (default $D = 50$, controlled by pack.depth).

Let $H(X)$ denote the empirical Shannon entropy of an object's payload byte stream $X$:

$H(X) = -\sum_{b=0}^{255} P(b) \log_2 P(b)$

The computational throughput of delta compression diverges fundamentally based on $H(X)$:

1. Low-Entropy Regime ($H(X) \le 4.5\text{ bits/byte}$): Source code, JSON payloads, and plain text files possess high string redundancy and limited symbol vocabularies. The LibXDiff algorithm rapidly identifies common blocks via Rabin-Karp hashing. The sliding window search terminates early because the delta size drops below the acceptable reduction threshold. In this regime, pack generation operates at high throughputs: $T_{\text{pack}} \approx 85\text{ to } 125\text{ MB/s per core}$ The resulting delta compression ratio $R_{\Delta} = 1 - \frac{\text{Size}(\Delta)}{\text{Size}(\text{Base})}$ routinely exceeds $0.85$ to $0.95$.
2. High-Entropy Regime ($H(X) \ge 7.5\text{ bits/byte}$): Pre-compressed media (JPEG, PNG, MP4), compiled binaries, encrypted payloads, or random data exhibit nearly uniform byte distributions. The symbol probability $P(b) \approx \frac{1}{256}$, maximizing entropy toward 8.0 bits/byte. Because no repeated substrings of length $L \ge 16$ exist, LibXDiff produces delta instructions whose compressed sizes exceed the original object size.
   
   The pack engine is forced to evaluate all $W$ candidate objects across the full window depth $D$, executing $O(W \times D)$ exhaustive sliding string matches per object before ultimately abandoning delta compression and falling back to a raw zlib literal store. Throughput collapses dramatically: $T_{\text{pack}} \approx 5\text{ to } 12\text{ MB/s per core}$ This creates an order-of-magnitude performance divergence, saturating CPU execution units and evicting hot pages from memory.

Working Memory Bounds During DAG Reachability and Packing

During topological traversal operations (such as git rev-list --all, commit-graph evaluations, and reachability boundary analysis), Git maintains a priority queue of commit nodes ordered by generation number and committer timestamp. The peak heap memory consumption $M_{\text{dag}}$ during a graph walk across $N_{\text{commits}}$ with maximum frontier width $F_{\text{max}}$ (the maximum number of concurrent branch heads or parallel branches being traversed) is bounded by:

$M_{\text{dag}} = O(F_{\text{max}} \times S_{\text{commit\_node}} + |V_{\text{commit}}| \times S_{\text{slab}})$

Where $S_{\text{commit\_node}} \approx 64\text{ bytes}$ and $S_{\text{slab}}$ represents Git's internal commit-slab allocator overhead (approximately 8 to 16 bytes per explored commit).

During packfile packing, memory consumption is strictly dominated by the sliding delta window buffer:

$M_{\text{window}} = W \times \min\left(\bar{S}_{\text{obj}}, \text{core.bigFileThreshold}\right) \times \mu_{\text{unpack}} \times N_{\text{threads}}$

Where $\mu_{\text{unpack}} \approx 2.5$ accounts for the uncompressed payload buffer, the Rabin hash-chain index, and delta match staging tables.

Mathematical Repository Footprint Calculator

The following production-ready Python calculator function models the exact memory and storage overheads of a Git repository across loose, packed, low-entropy, and high-entropy operational profiles.

from __future__ import annotations
import math
from typing import Dict, Any

def calculate_git_memory_footprint(
    object_count: int,
    avg_uncompressed_bytes: int,
    entropy_profile: str = "low",
    window_size: int = 10,
    pack_threads: int = 8,
    fs_block_size: int = 4096,
    inode_table_bytes: int = 256
) -> Dict[str, Any]:
    """
    Calculates theoretical storage, memory bounds, and packing throughput
    for a Git repository state under varying data entropy regimes.

    Args:
        object_count: Total number of discrete Git objects to model.
        avg_uncompressed_bytes: Average uncompressed payload size per object.
        entropy_profile: 'low' (source code) or 'high' (compressed binaries).
        window_size: pack.window sliding candidate count.
        pack_threads: Concurrency factor during object packing.
        fs_block_size: Filesystem cluster allocation block size (bytes).
        inode_table_bytes: Filesystem metadata footprint per allocated inode.

    Returns:
        Structured dictionary detailing loose storage, packed storage,
        slack waste, peak packing RAM, and projected packing throughput.
    """
    if object_count < 0 or avg_uncompressed_bytes < 0:
        raise ValueError("Object count and payload size must be non-negative integers.")

    envelope_overhead = 24  # Type string, space, length ASCII, and null byte
    raw_size_per_obj = avg_uncompressed_bytes + envelope_overhead

    if entropy_profile == "low":
        # Low entropy: text/code compresses ~65% with zlib; delta yields ~85% reduction
        zlib_ratio = 0.35
        delta_ratio = 0.15
        delta_applicable_fraction = 0.80
        throughput_mb_s = 95.0
    elif entropy_profile == "high":
        # High entropy: minimal zlib gain; deltas almost universally fail
        zlib_ratio = 0.98
        delta_ratio = 0.95
        delta_applicable_fraction = 0.05
        throughput_mb_s = 8.5
    else:
        raise ValueError("Invalid entropy_profile. Choose 'low' or 'high'.")

    # 1. Loose Object Footprint Modeling
    single_loose_compressed = math.ceil(raw_size_per_obj * zlib_ratio)
    # Total physical blocks consumed on disk per loose object
    blocks_per_loose = math.ceil(single_loose_compressed / fs_block_size)
    physical_bytes_per_loose = blocks_per_loose * fs_block_size
    
    total_loose_disk_bytes = (
        object_count * physical_bytes_per_loose
    ) + (object_count * inode_table_bytes)
    
    actual_loose_payload_bytes = object_count * single_loose_compressed
    filesystem_slack_waste_bytes = total_loose_disk_bytes - actual_loose_payload_bytes

    # 2. Packfile Footprint Modeling
    # A fraction of objects become delta children, others remain base objects
    base_object_count = object_count * (1.0 - delta_applicable_fraction)
    delta_object_count = object_count * delta_applicable_fraction

    packed_base_bytes = base_object_count * (raw_size_per_obj * zlib_ratio)
    packed_delta_bytes = delta_object_count * (raw_size_per_obj * zlib_ratio * delta_ratio)
    
    # 12 bytes pack header + 20 bytes SHA trailer
    pack_data_bytes = 12 + packed_base_bytes + packed_delta_bytes + 20
    
    # .idx v2: 1024 (fanout) + N*20 (SHA table) + N*4 (CRC32) + N*4 (Offset) + 40 (checksums)
    idx_v2_bytes = 1024 + (object_count * 28) + 40
    total_packed_disk_bytes = math.ceil(pack_data_bytes) + idx_v2_bytes

    # 3. Peak Runtime Packing Memory (Sliding Window RAM)
    # Memory multiplier for window: uncompressed buffer + Rabin fingerprint index tables (~2.5x)
    unpack_overhead_multiplier = 2.5
    peak_packing_ram_bytes = math.ceil(
        window_size * avg_uncompressed_bytes * unpack_overhead_multiplier * pack_threads
    )

    # 4. Processing Duration
    total_uncompressed_mb = (object_count * avg_uncompressed_bytes) / (1024 * 1024)
    estimated_packing_seconds = total_uncompressed_mb / (throughput_mb_s * pack_threads)

    return {
        "object_count": object_count,
        "entropy_profile": entropy_profile,
        "loose_total_disk_mib": round(total_loose_disk_bytes / (1024 * 1024), 2),
        "loose_slack_waste_mib": round(filesystem_slack_waste_bytes / (1024 * 1024), 2),
        "packed_total_disk_mib": round(total_packed_disk_bytes / (1024 * 1024), 2),
        "storage_reduction_factor": round(total_loose_disk_bytes / total_packed_disk_bytes, 2),
        "peak_packing_ram_mib": round(peak_packing_ram_bytes / (1024 * 1024), 2),
        "projected_repack_seconds": round(estimated_packing_seconds, 2),
    }

# Concrete Numerical Execution Example
if __name__ == "__main__":
    low_entropy_run = calculate_git_memory_footprint(
        object_count=100000,
        avg_uncompressed_bytes=3072,  # 3 KB average file
        entropy_profile="low",
        window_size=10,
        pack_threads=8
    )
    high_entropy_run = calculate_git_memory_footprint(
        object_count=100000,
        avg_uncompressed_bytes=3072,
        entropy_profile="high",
        window_size=10,
        pack_threads=8
    )

    print(f"Low-Entropy Repo Disk: Loose={low_entropy_run['loose_total_disk_mib']} MiB | Packed={low_entropy_run['packed_total_disk_mib']} MiB | Ratio={low_entropy_run['storage_reduction_factor']}x")
    print(f"High-Entropy Repo Disk: Loose={high_entropy_run['loose_total_disk_mib']} MiB | Packed={high_entropy_run['packed_total_disk_mib']} MiB | Ratio={high_entropy_run['storage_reduction_factor']}x")

3. Production Trade-Offs & Benchmarks

Git's dual-format storage system—loose objects versus packed aggregates—represents an architectural trade-off between write ingestion latency and read/traversal efficiency.

Contiguous versus Segmented Block Allocation

In a clean or actively mutating repository, new changes are initially recorded as loose objects. Each object is allocated as a segmented, isolated file on the underlying POSIX filesystem. Over time, or via automated garbage collection thresholds, Git serializes these fragmented allocations into contiguous packfiles accessed via memory mapping (mmap).