编程与软件工程dhwthompson.com
我最喜欢的一个 Git 提交（2019）
My favourite Git commit (2019)
2020 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者挑出自己最喜欢的一次 Git 提交：那次提交的信息写得像一篇长文，完整记录了排查过程——一个看不见的异常空白字符（不换行空格）导致测试失败，最终只改动了一个字符。文章借此讨论 commit message 应当记录“为什么”而不只是“改了什么”。
为什么经久不衰：它把一次微不足道的修复写成侦探故事，多年来持续提醒开发者：提交信息是留给未来自己和同事的推理档案。
HN 评论精选
批评文章只讲故事、没讲清编码层面的根因，实用性有限。
作者花了全部篇幅记录自己的排查过程，却完全没有解释问题的真正原因：如果文件里是 UTF-8 字节序列，为什么会被当作 US-ASCII 解析？我明白那只是个错误的空格，但如果哪天有人真的因为某种原因要在那里放一个 UTF-8 字符，这篇 commit 长文一点忙也帮不上。
bassdigit查看英文原文
The author spent all the time documenting his journey but totally fails to explain the actual reason of the problem: If the file contains a UTF-8 byte sequence, why is there an attempt to parse it as US-ASCII? I get that it's just a wrong space, but if some day somebody actually want to put a UTF-8 char there for some reason, this commit essay wouldn't help at all whereas googling stackoverflow seems to deliver (unverified): https://stackoverflow.com/questions/15947425/rake-tasks-fail-with-invalid-byte-sequence-in-us-ascii
质疑修复是否只影响测试，并反思测试本身的成本与价值。
我只是好奇……除了这个 spec，它真的修复了什么吗？我问是因为我发现（尤其在 Rails 里）自己花大量时间维护几年前更没经验的自己写的测试，并慢慢意识到很多被测试的东西其实并不重要。我不是说作者不该写这个 spec，但也许真正的 bug 是 rspec 的匹配器不认 UTF-8 空格。
jspash查看英文原文
I'm just curious but... did this actually fix anything other than the spec? The reason I ask is that I find myself (with Rails particularly) spending an awful lot of time on maintaining tests that were written by a much younger and much less experienced developer (me, a few years ago). And I've come to the slow realisation that a lot of what I was testing wasn't really important. I'm not saying the author shouldn't have written the spec, or that the spec wasn't valuable. But maybe the true bug here was that rspec matchers don't honour utf-8 spaces and perhaps they should? I dunno. Just thinking out loud here.
认同记录理由的价值，但现实中好信息常被同事和 squash 流程消解。
我也用 commit message 记录改动背后的理由，但不确定同事是否注意到，因为他们常写「Fix bug」这类信息。我还经常发现自己的提交信息在审查时被 squash 掉了。你有什么建立良好提交信息文化的建议吗？
pvorb查看英文原文
I, too, use git commit messages to document the reasoning behind my changes. But I'm unsure if my colleagues even notice, since they regularly write bad commit messages like "Fix bug" and things like that. Also I regularly find my commit messages got lost, since the reviewer squashed several commits into one. Do you have any tips for establishing a culture of good commit messages?
历次讨论
同类还值得读
开源应用架构
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编辑精选