编程与软件工程sqlite.org编辑精选
为什么 SQLite 不使用 Git
Why SQLite Does Not Use Git
2018 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 SQLite 官方的一篇说明文，解释 SQLite 项目为什么坚持使用自研的 Fossil 而不是 Git。作者逐条列出理由，包括 Git 的心智模型过于复杂、不记录历史上的分支名、缺少一目了然的时间线/提交图视图，以及 GitHub 等平台对合并历史的展示不够直观。
为什么经久不衰：它提供了一个罕见的、来自顶级项目维护者的反面视角，让人重新审视 Git 被默认接受的复杂性和工具设计取舍，讨论价值远超 SQLite 本身。
HN 评论精选
Git 的复杂性导致团队成员各自只懂一部分，互相教学成为常态。
「没人真正懂 git」是全文最真实的一句。虽然有点夸张，但确实很有道理。和团队协作时总让人沮丧：每个人理解的是 git 的不同部分，对该怎么做事也有略微不同的想法。我还经常要向别人解释什么是 rebase，别人也经常要向我解释 blob 到底是什么。在一个中等规模的团队里，互相教和学 git 是常态化的工作。人们说 git 底层很简单，只要学会它的内部模型就能忽略复杂的默认 UI，我不同意——光是学内部模型就会不断遇到意外，比如我老是记不住 blob 为什么不干脆叫文件。
jordigh查看英文原文
"Nobody really understands git" is the truest part of that. While hyperbolic, it really has a lot of truth. It's always a bit frustrating when working with a team because everyone understands a different part of git and has slightly different ideas of how things should be done. I still routinely have to explain to others what a rebase is and others have to routinely explain to me what a blob really is. In a team of the most moderate size, teaching and learning git from each other is a regular task. People say git is simple underneath, and if you just learn its internal model, you can ignore its complex default UI. I disagree. Even just learning its internal model leads to surprises all the time, like the blobs that I keep forgetting why aren't they just called files.
逐条反驳：Git 也能做这些事，复杂换来了实用功能，部分抱怨其实针对 GitHub 的 UI。
我没用过 Fossil，只按页面顺序评论几点：1）第一点我没看懂。是的，git 不存储类似双向链表的提交结构，所以找「下一个」提交更费劲，但可以用 'git log --reverse <commit>..' 做到，在 sqlite.git 上很快。大仓库会慢很多，不过 git 相对容易加一个侧面的反向索引来加速。2）确实 index 等很多东西很复杂，但我好奇「git add -p」这类操作在 Fossil 里怎么做，我猜完全不行。能增量地暂存合并冲突吗？很多复杂性都带来了显著的好处。3）这里把两件无关的事混在一起：一是 GitHub 默认不展示类似 'git log --graph' 的输出，二是他假设 git 对 master 分支有特殊处理。GitHub 等查看器可以特判主分支并把信息显示在顶部，但同样的信息 git 里本来就有，所以这只是在抱怨某个具体网页 UI。
avar查看英文原文
I haven't used Fossil, but just a comment on some of that page, in the order they're presented: 1. It's unclear to me what he means. Yes git doesn't store anything like a doubly linked list of commits, and thus finding the "next" commit is more expensive, but you can do this with 'git log --reverse <commit>..', and it's really snappy on sqlite.git. It's much slower on larger repositories, but git could relatively easily grow the ability to maintain such a reverse index on the side to speed this up. 2. Yeah a lot of the index etc. is complex, but I wonder how something like "git add -p" works in Fossil. I assume not at all. Is there a way to incrementally "stage" merge conflicts? Much of that complexity comes with significant advantages. 3. This is complaining about two unrelated things. One is that GitHub by default isn't showing something like 'git log --graph' output, the other is that he's assuming that git treats the "master" branch magically. Yeah GitHub and other viewers could grow some ability to special-case the main branch and say "..and this was merged into 'master'" at the top of that page, but in any case all the same info exists in git as well, so it's just a complaint about a specific web UI.
认同 Fossil 时间线的信息密度，批评 GitHub 隐藏提交树导航。
文中说：「我想看 SQLite 最近发生了什么时，就去看时间线，一屏之内就能看到所有分支上最新变更的摘要，点几下就能下钻到任意细节，甚至在手机上也能做。GitHub 和 GitLab 没有可比的东西，最接近的是 network 视图，渲染慢（除非已缓存）、细节少得多，在移动端几乎不能用。」这个观点很有道理。我一直奇怪为什么 GitHub 似乎刻意隐藏了许多 git 客户端（Sourcetree、gitk、tortoisegit 等）都支持的提交树导航。
loudthing查看英文原文
"When I want to see what has been happening on SQLite, I visit the timeline and in a single screen I see a summary of the latest changes, on all branches. In a few clicks, I can drill down as much detail as I want. I can even do this from a phone. GitHub and GitLab offer nothing comparable. The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile." This is a valid point. I've always wondered why it seems Github goes out of its way to hide the typical commit tree navigation that so many git clients support (Sourcetree, gitk, tortoisegit, etc).
历史分支名无法追溯是实际痛点，技术上似乎容易补上。
文中「Git 不记录历史上的分支名」这一条是我最在意的。git 的分支本质上只是某个提交历史的 HEAD 指针，如果过去发生过大量合并，就很难看出某个提交当时属于哪个分支。有好的解决办法吗？加一条元数据记录提交时所在的分支，似乎轻而易举。
hn_throwaway_99查看英文原文
> Git does not track historical branch names That's my biggest pet peeve on this list. Git branches are really just pointers to the HEAD of some commit history, but if you've had a bunch of merges in the past it can be very difficult to tell which commit belonged to a particular branch at some point in the past. Is there a good solution for this? Seems like it would be trivial to add a piece of metadata about which branch someone was on when a commit was made.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选