HN Weekly 中文
← #806

Cursor 推出 Origin，对标 GitHub 的代码托管平台

查看原文 HN 讨论

文章摘要

2026 年 8 月 17 日，Cursor（母公司 Anysphere）发布 Origin——自家的 Git 代码托管服务，以 early beta 形式向所有付费用户开放（企业版组织的管理员可选择退出）。首批功能刻意做得「朴素」：仓库、Pull Request、代码浏览、以及与 GitHub 的双向同步。新增的 Codebase 标签页是 Origin 仓库的入口，点 +New 建仓后页面会给出安装 CLI、clone 或 push 本地项目的命令；codebase 名字会成为所有仓库 URL 的一部分（cursor.com/codebase/acme-corp）。GitHub 仓库可以和 Origin 自托管仓库并列摆放：连接 GitHub、选组织、挑仓库同步进来，同步是实时的，但 push 仍然走 GitHub——GitHub 保持为「源自那边」内容的真实来源。PR 评论双向同步：在 Cursor 里评论会发到 GitHub，在 GitHub 上回复几秒内出现在 Cursor。App 生态已接入 Vercel（每个 PR 自动预览部署）、Depot 和 Buildkite（两者都能跑现有的 GitHub Actions workflow，Buildkite 还支持自己的原生 pipeline）。

真正的技术料在配套博客《Git at Any Scale》（作者 Vicent Martí，libgit2 作者）里。文章先复盘业界历史：Shawn Pearce 在 Google 用 JGit + 分布式哈希表存 Git 对象，因为 Git 协议强制走 packfile，git clone 性能太差而作废；GitHub 早年试过 NFS、GFS、DRBD 等分布式文件系统方案，全部撞墙，因为 packfile 里对象是随机排布 + delta 压缩的，每次 Git 操作都要在几 GB 数据里随机游走，网络文件系统扛不住。GitHub 2013 年做出的 Spokes 成了行业标准，三个正确选择是：不分布 Git 本身而在 packfile 层做、把数据以真实 Git 仓库形式存在本地 NVMe、复制但保持强一致。Spokes 用 3PC（三阶段提交）同步 reference transaction（packfile 可以无同步地并行 fan-out，因为提交在 ref 更新前不可达）。但 3PC 的水平扩展性有硬伤：延迟受集群最慢节点约束，副本越多 push 吞吐越差；三副本对 2026 年的巨型 monorepo（尤其是 CI 流量）不够用，而对 agent 批量生成的海量小仓库又太奢侈——「下限太高，上限太低」。加上磁盘仓库即真实来源，仓库只能当宠物养，需要外部数据库维护巨大路由表 + 校验和 + 修复任务。

Cursor 的方案叫 Continuity：核心原语是存在 S3 兼容对象存储里的 write-ahead log。每次 push 作为独立对象写入 WAL，未完全持久化前绝不 ack；push 只有在本地仓库副本上成功 prepare reference transaction 并把指针记入 WAL index 后才可见，从而让所有 push 线性化。没有路由表、没有关系数据库、没有选主：仓库位置用 rendezvous hashing 推算，本地没有就从 WAL 物化出来；WAL 更新靠 S3 的原子 CAS，任何节点都能当 primary。复制用 UDP gossip 做乐观通知，丢包也无所谓——每个副本记住自己追到的 WAL index ETag，读请求时对 S3 发条件 GET，304（平均低于 10ms 的纯元数据操作）就直接服务，200 就先追平再服务。压缩（repack）只由 primary 做，副本直接从 S3 下载压好的 pack，用带宽换 CPU。压力测试跑到 100 个副本，读吞吐线性增长且不影响 push；S3 Standard 下可持续 120 pushes/s，换成 S3 Express One Zone 超过 300 pushes/s，此时瓶颈已是 Git 自身在磁盘上做 compaction 的速度。作者点名对比 Azure DevOps（把 packfile 放 blob 存储、ref 放 MS SQL Server），认为 Git 数据一致性高于一切，才选了不依赖外部数据库的 WAL 设计——因为每一次 push 和 repack 都有完整溯源，踩到 Git 的 bug 时可以精确定位并回滚，还能任意 rewind/fast-forward 副本。基准数据用的是 Cursor 自己的 monorepo everysphere。

HN 评论精华

这条帖子拿到 595 分、约 410 条评论，但讨论主线几乎与技术无关：绝大多数篇幅在争论「要不要把源码交给 Elon Musk 旗下的公司」（Cursor 已被 xAI/SpaceX 系收购，评论里各种「spacexai」「SpaCursoreXAI」的调侃），以及 GitHub 最近频繁宕机的成因。真正讨论 WAL + 对象存储架构的只有零星几条。Origin 团队成员、Graphite 联合创始人 tomasreimers 全程在场答问。