Git at any scale
Cursor explains why Git hosting resists naive distribution: DAG walks and delta-packed files punish network round trips, favoring local NVMe replicas kept consistently in sync.
Git operations traverse a **content-addressed DAG** whose next pointer is discovered only after fetching the current object. Packfiles add scattered, delta-compressed reads, making object stores and network filesystems costly for routine operations.
Builders of agent infrastructure should keep repository operations close to local storage and treat Git protocol compatibility, clone behavior, and read-after-write consistency as architectural constraints. The established pattern replicates whole repositories at the packfile level on **local NVMe**.
Git operations traverse a **content-addressed DAG** whose next pointer is discovered only after fetching the current object. Packfiles add scattered, delta-compressed reads, making object stores and network filesystems costly for routine operations. Builders of agent infrastructure should keep repository operations close to local storage and treat Git protocol compatibility, clone behavior, and read-after-write consistency as architectural constraints. The established pattern replicates whole repositories at the packfile level on **local NVMe**. That pattern improves horizontal scale without making one repository intrinsically distributed: copies must remain **consistently in sync**. The provided material explains the tradeoff but does not give Cursor’s own performance measurements or full implementation.
This narrows the architecture for repository-backed cloud agents: Git’s dependent DAG traversal and scattered packfile reads favor full local NVMe replicas over remote object-by-object access. Horizontal scaling therefore comes from synchronized repository copies, not from making a repository transparently distributed, leaving consistency as the central systems obligation.