二十年不算什么

原文 ↗ Hacker News 讨论 ↗

版本控制从 SourceSafe、CVS 这类基于锁的中心化系统，演进到 Git 这种“历史无处不在”的分布式模型；许多人认为它带来了变革，但仍然只是一个不完美的平台。评论者一方面肯定 Git 的速度和稳健性，另一方面批评其令人困惑的 UX、对超大型或二进制仓库的糟糕支持，以及缺乏语义化或 AST 感知的历史记录，并把 Mercurial、Fossil、Pijul、jj 和基于 CRDT 的设计看作弥补这些缺口的尝试。讨论还强调了实现选择（例如 Rust 对比 Python）、工作流模式（rebase、堆叠提交）以及托管平台（GitHub 对比自托管）如何共同塑造工具质量和开发者文化。

实现语言与“用 Rust 编写”

  • 围绕项目为什么会宣传“用 Rust 编写”展开了反复讨论。
  • 支持者认为语言选择传达了：
    • 没有 GC 也能做到内存安全和高速度。
    • 静态、自包含的二进制文件，以及顺畅的工具链。
    • 一种重视正确性和性能的开发者文化。
  • 怀疑者则认为这更像是薄弱的营销：如果“用 Rust 编写”就是头条卖点，那项目可能没什么别的可区分之处。
  • 也有人指出，语言会预测项目风格和生态适配性（例如，如果你懂 Rust/Go，而不是 Python，更容易参与贡献）。
  • 对 Python/JS 在性能和长期稳定性方面的批评；Go 被提到在分发方式上类似 Rust，但在类型/所有权保证上并不相同。

Pijul、基于补丁的 VCS，以及 CRDT 思路

  • Pijul 和 Fossil 被强调为真正不同于 Git 的替代品；jj 和 Sapling 则更像是改进版的 Git/Mercurial 界面。
  • Pijul 的作者解释：
    • 设计基于补丁/CRDT；冲突是模型的一部分。
    • 数据结构最初是“像理论家那样”设计的，然后再优化。
    • 自定义的 Rust 键值存储（Sanakirja）支持快速、通用、适合 mmap 的存储和高效 fork，并且在他们的基准测试中优于 LMDB。
    • 选择 Rust 是出于务实考虑：它能提供底层控制，又没有 C++ 那种调试痛苦；如果放到今天，考虑到语言演进，可能会选 Zig。
  • 也有人认为，基于补丁的 VCS 在大型仓库、冲突、blame 以及二进制文件方面，可能比基于快照的 Git 更快。

Git 的优点、缺点与工作流

  • Git 广受好评，原因包括：
    • 相比更老的工具更快。
    • 分布式工作流和离线提交。
    • 灵活且强大的数据模型。
  • 批评包括：
    • CLI 体验令人困惑；很多概念泄露了内部实现。
    • rebase、重写历史以及堆叠提交工作流都很难；Gerrit、Graphite、jj 等工具试图缓解这些问题。
    • Git 存的是快照，不是显式的变更历史；文件重命名/拆分和大型重构很难追踪。
    • 没有空目录；对文件拆分/合并和语义迁移的历史支持较弱。
    • 一些人认为 Git LFS 脆弱且在运维上笨拙。

中心化、历史大小与部分克隆

  • 讨论的一个点是，20 年前“把完整历史克隆到本地”是不是“不可想象”的；有些人回忆起 CVS/SVN 配合本地脚本，以及当时足够大的磁盘，另一些人则强调当年的网络和存储限制。
  • 还有观点认为 DVCS 意味着一个现实上限：仓库历史必须能装进最小的开发者笔记本。
  • 有人认为，大多数组织事实上都是中心化的，因此会受益于层级/从属克隆：只保留部分历史、部分树，但仍然能在本地分支和提交。
  • 也提到了较新的 Git partial clone 和 sparse-checkout 功能，作为部分解决方案。

二进制资产与非文本项目

  • Git 以文本为中心的模型对大多数软件都很适用，但：
    • 游戏、芯片设计和媒体流水线由于大量二进制文件，仍更偏爱 Perforce 或 SVN。
    • Git LFS 被批评有 bug、运维复杂，并且需要额外的服务器组件。
    • 有人希望 VCS 能原生理解二进制格式（例如对图片做语义 diff）和大文件存储；Pijul 声称支持原生二进制。

语义化、AST 感知与基于 CRDT 的未来

  • 多位评论者建议：
    • 对 AST 或特定领域结构进行版本控制，而不是仅对原始文本进行控制。
    • 更好的 diff/conflict 能理解移动、重命名和重构。
  • 有一个提议：做一个 Git 继任者，存储字符级 CRDT 历史，支持实时协作和语义提交；尚未解决的问题包括冲突展示和数据删除（机密信息）。
  • 也有人认为这种粒度会增加噪音和复杂性；由人来选择的提交点作为检查点仍然很有价值。

历史工具与视角

  • 大量怀旧地提到了 VSS、ClearCase、Perforce、CVS、SVN、RCS、BitKeeper，以及临时用 zip/tar 做“版本管理”的做法。
  • 基于锁的中心化系统（VSS、某些 ClearCase/Perforce 配置）被记忆为痛苦，但一度被视为“专业工具”；开源世界中使用 CVS/SVN 的工作流，则被看作领先于很多企业。
  • 普遍的感觉是，每一代人都觉得自己的工具已经不错，直到下一次重大跃迁（SVN，随后 Git/DVCS）暴露了它们的局限。

会有东西取代 Git 吗？

  • 有人认为 Git 已经到达演化平台；继任者必须满足：
    • 与 Git 完全兼容，并能透明地使用现有仓库。
    • 更简单的 UX 和更好的语义（重命名、AST 感知操作、堆叠提交）。
    • 更好地处理大型仓库和二进制文件。
  • 也有人预计 Git 终将被替代，因为 VCS 轮替有很长历史；不过，Git 的网络效应和“足够好”状态，可能会让它在很长时间里仍然占主导地位。