Cursor 长文 Git at any scale 在讲什么

cursor git at any scale 讲什么？Cursor 在 Git at any scale 把「自托管 Git 有多难」写成系统文：不是产品 changelog，而是为什么简单把 HTTP 怼在磁盘仓库前面会撞墙，以及他们要重做哪一层。读它比只看 Origin 开箱声明更能判断：你遇到的慢 clone / 推不动 / CI 偶发找不到 commit，到底是客户端问题还是宿主架构问题。

作者：CodePass 技术编辑

packfile 为何难水平扩展

Git 客户端协议强制收发包文件。对象是 DAG，读一次「最近提交」要跟着指针跳；对象在 pack 里又常是 delta，物理上也是随机跳。把仓库丢进 NFS / 块级复制文件系统时，这种访问模式几乎必然变慢。把每个对象拆进分布式 KV 也试过：协议仍要吐 pack，git clone 表现往往差到放弃。

业界后来收敛到 Spokes 一类做法：本地 NVMe 上放真仓库、按 pack 复制、用三阶段提交保证引用事务一致。读可以从任意副本走，因为副本总是对齐的。这套模型撑了很多年，也成了多数托管商的骨架。

Spokes 在 2026 的两头夹逼

文中点名两处结构性痛。一是企业 monorepo + 海量 CI：三副本不够吃流量，但 3PC 副本越多，推送吞吐越被最慢节点拖死。二是 agent 时代反过来造海量小仓、很多几乎闲置：Spokes 仍要为一致性付三副本地板，闲仓也贵。运维上仓库像宠物：路由表、校验和、坏盘修复都绑在「磁盘上的仓是共识真相」上，两份坏了就可能丢法定人数。

Cursor 自家后续系统叫 Continuity（Cnt）：声明继承 Spokes 里「本地 Git + 强一致」的优点，改掉副本地板过高、天花板过低和运维宠物化。产品面上对应的是 Origin 托管与 GitHub 同步；产品入口说明见 Cursor Origin 是什么，故障时同步仓怎么退回 GitHub 见 Origin GitHub 故障怎么办。

对使用者意味着什么

你不需要复刻 Continuity。需要的是选型时问对问题：仓是巨型 monorepo 还是 agent 抛出的一次性小仓？CI 扇出有多大？若 Origin 仍早鸟，把「浏览与 Agent 同屏」当体验增益，把「灾备与合规」继续钉在你已验证的宿主上，直到 SLA 与迁移路径写进合同。