编程与软件工程wincent.com
Git 之争：Bram Cohen 对 Linus Torvalds
Git: Bram Cohen vs Linus Torvalds
2009 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章回顾早期 Git 诞生时 Bram Cohen 与 Linus Torvalds 围绕版本控制和合并设计的交锋，尤其是“是否需要重命名跟踪等复杂元数据”这类问题。页面把两人的不同思路放在一起，帮助理解 Git 为何选择只跟踪树的内容状态。
为什么经久不衰：它把 Git 的简单设计哲学放回早期争论中，今天读仍能明白 Git 为何能迅速胜出并改变版本控制实践。
HN 评论精选
Linus 的优势来自近二十年真实合并实战经验，而非正式研究合并算法。
我认为 Bram 错在以为自己对合并算法的研究和实验，能让他比看似新手的 Linus 更有洞察力。他忽略的是，Linus 近二十年大部分时间都在用各种不够好的工具做合并，无疑经常被迫手工编辑成千上万个补丁才能成功合并。当 Linus 开始那个两周项目时，他带来了在庞大复杂代码库、大量贡献者环境下做真实合并的极其丰富的经验。而且他是个很有洞察力的人。所以，虽然他没有花那么多时间正式研究深奥细节，Linus 对合并密集的开发流程产生的日常问题以及如何解决它们有很好的洞察。
swillden查看英文原文
I think an Bram errs when he thinks that his experience in studying and experimenting with merge algorithms gives him deeper insight than the apparent newcomer to the field, Linus. What he's missing is that Linus has spent a large part of nearly two decades doing merges using a variety of inadequate tools which no doubt frequently forced him to hand-edit many thousands of patches in order to get successful merges. When Linus sat down to start his two-week project, he brought with him an incredibly rich base of experience with real-world merging of changes in a significant, complex codebase with large numbers of contributors. Also, he's an insightful guy. So while he may not have spent as much time in formal study of the esoteric intricacies, Linus had great insight into the day-to-day issues that merge-heavy development processes create, and how to solve them.
Linus 强在识别并解决真正影响开发者的问题，Git 因此迅速胜出。
我认为 Linus 的长处——这篇文章指出的正是其中一例——是发现正确的问题，而不一定是解决问题时有多么天才（不过他也很擅长解决问题）。我怀疑 Bram 和 Linus 一样有才华，但在他追逐深奥问题的优雅解法时，Linus 发现并解决了对开发者影响最大的问题，Codeville 错过了船。我认为版本控制战争未来几年基本结束了，Git 以巨大优势获胜。这本身就说明了 Linus 的天才：他造的东西有几十个竞争者，有些还有 Canonical 的 bzr 这种大靠山，但几个月内几乎所有人都清楚 Git 占据了下一代版本控制的心智份额。他的方案很丑，只是一些 C 和 Perl 脚本短时间拼起来，但它在正确的时间解决了正确的问题。
SwellJoe查看英文原文
Linus' strength, I think, and this article is pointing out one particular instance of that strength, is in spotting the right problem...not in any particular brilliance in solving the problem (though he's pretty good at solving the problems, as well). I suspect Bram is as talented a developer as Linus, but in chasing down elegant solutions to esoteric problems while Linus spotted and solved the problems that most effect developers, Codeville has missed the boat. I suspect the revision control wars are pretty much over for the next few years, and git won by a large margin. That, in and of itself, is an interesting indication of Linus' genius...he built something that had dozens of competitors, some with major backing like Canonical's bzr, and within a couple of months it was apparent to just about everyone that git had the mindshare for next generation revision control. His solution was ugly, just some C and Perl scripts thrown together in a short period of time, but it solved the right problems at the right time.
Git 只跟踪树的内容状态，重命名等由内容差异隐含推导，这种简单模型让人真正理解并接受 Git。
这篇文章带回回忆。2007 年我刚看过 Linus 在 Google 的 Git 演讲，当时觉得 Git 可能只是一时风潮。但后来这篇文章让 Git 终于在我脑中豁然开朗。关键引文是：不需要花哨的元数据、重命名跟踪等等。你唯一需要存的是每次变更前后树的状态。哪些文件被重命名？哪些被复制？哪些被删除？哪些行被添加、删除或修改？哪些文本块从一个文件复制到另一个？你不该关心这些问题，也不该为回答它们保留特殊跟踪数据：对树的所有变更都隐含在树两个状态之间的 delta 中；你只需跟踪内容是什么。用了 Git 七年，我无法想象以前怎么用不基于整棵树的版本控制。
solutionyogi查看英文原文
This article brings back memories. Back in 2007, I had just watched Linus' presentation on Git at Google (http://www.youtube.com/watch?v=4XpnKHJAok8) where he called all non distributed version control systems as useless. I could not make any sense of the DVCS from his talk. I tried to play with Git and it was extremely frustrating due to the poor CLI. I thought may be Git is just a fad. But then more and more people kept talking about how awesome it is. This was one of the article where Git finally clicked for me. The key quote: There is no need for fancy metadata, rename tracking and so forth. The only thing you need to store is the state of the tree before and after each change. What files were renamed? Which ones were copied? Which ones were deleted? What lines were added? Which ones were removed? Which lines had changes made inside them? Which slabs of text were copied from one file to another? You shouldn't have to care about any of these questions and you certainly shouldn't have to keep special tracking data in order to help you answer them: all the changes to the tree (additions, deletes, renames, edits etc) are implicitly encoded in the delta between the two states of the tree; you just track what is the content. It's been 7 years since I have been using Git and I can't imagine how I ever worked with version control which didn't work on the entire tree.
不能等学术定论才动手，实践和试验本身推动创新。
链接文章里有一句很妙的话：“也许有一天有人会就这个主题写一篇博士论文，然后我们再把它加进去，但在那之前我们坚持基本功能。”我想，如果每个人都等某个主题的博士论文发表，而不是试验自己的想法，那就不会有太多创新了。
adambyrtek查看英文原文
There is a lovely quote in the linked post: "Maybe someday somebody will do a PhD thesis on that topic and we'll add it, but until then we're sticking with the basic functionality." I guess not much innovation would happen if everybody waited for a PhD thesis to be published on a given subject instead of experimenting with their own ideas.
历次讨论
同类还值得读
开源应用架构
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编辑精选