逃离Git：为何我转向Fossil
From Git to Fossil
面对Git社区强制转向Rust的提议，我决定寻找替代方案。作为经历过RCS、CVS、SVN等版本控制系统的老用户，我重新审视了Fossil。它用C语言编写，轻量高效，没有Git中复杂的暂存区，且自带Web服务器、Wiki和工单系统，无需依赖GitLab或Gitea等额外软件。Fossil允许自托管，提交信息使用用户名而非邮箱，有效避免垃圾邮件，同时支持与Git双向同步。我详细记录了从安装Fossil、迁移Git仓库到搭建自托管服务器的全过程，并对比了两者在克隆、查看状态和差异对比等日常操作上的异同。如果你也厌倦了过度复杂的工具链，Fossil或许是个更自然的选择。
当我看到一个项目试图“强制”使用或从C转向Rust时，我会像被《指环王》中的巴尔罗格拿着鞭子追赶一样逃离它。
HN 评论区
38- LVB
Fossil 让我感到极其沮丧。它有很多吸引我的地方，但总有一些致命缺陷阻碍了我真正采用它。我认真使用过它好几次。问题的根源在于他们对不可变性的坚持。最臭名昭著的是不支持 rebase，但你甚至无法编辑工单描述！如果在描述中打错字或犯个错，你只能追加更多备注，或者删除并重新创建工单。
我真的很喜欢这样一个强大的、打包好的 scm + 工单等系统的理念，我也是 sqlite 的粉丝，但 Fossil 对我而言并不奏效。
- sugarkjube
很久以前我就看过 Fossil，当时非常喜欢，但最终选择了 Git，因为它更“标准”。我想我得重新审视一下 Fossil 了。
题外话，我挺喜欢这篇文章的样式表。
- ianjbutler
在我看来，如今 Fossil 最好也最相关的部分是它的工单系统，它在方方面面几乎都完美契合代码代理（coding agents）的需求。一些特性包括：单二进制文件、仓库内集成、CLI 或 Web 界面，以及对离线/SQL/Markdown 友好。
既然整个追踪器本质上只是基于 sqlite 的一个薄前端，并具备上述特性，那么用法就很多了。你可以按项目持久化使用以包含同事，或者仅本地使用，让你的代理在其中“思考”，这样它们就不太可能把思维链（CoT）全堆在代码注释里。甚至可以按任务粒度使用，用完即弃。这三种方式都可以，Fossil 不在乎！代理们会爱上它的。
- camkego
我真心觉得这篇文章误解了 Git 邮件列表的那封邮件。
文章第一行写道：
“Git 方面已开始着手一项提案，将 Rust 编程语言设为强制要求。”
这听起来像是所有未来的代码都必须用 Rust 写。
但 Git 邮件列表的邮件原文是：
“宣布 Git 3.0 将把 Rust 作为我们构建基础设施的强制组成部分。”
此外，原始 Git 邮件列表邮件还提到：
“[作者正在将...] 'varint.c' 子系统移植到 Rust，主要是因为这部分代码很简单且没有任何依赖。”
所以，Git 列表上的邮件说的是他们正在尝试将一小段 C 代码改为 Rust，并且 Rust 构建工具将成为强制要求（如果代码库中有一部分非可选的 Rust 代码，这并不奇怪）。
- thangalin
如果你只是想要一个简单的只读 Web 界面来展示 Git 仓库，解决方案有很多。这是我的：