加载失败
这是 Ted Nyman 的《High Performance Git》相关内容，网站 gitperf.com 以章节形式讲 Git 在大仓库、频繁分支和大量元数据下的性能问题。评论把它和 `git clone --depth 1`、`--filter=blob:none`、Git LFS（Git Large File Storage，大文件外置存储方案）等实际工具联系起来，讨论如何减少 clone、push 和文件内容拉取的成本。由于 Git 的设计同时要服务 Linux kernel 这类超大协作项目和只想“安装一下源码”的普通用户，评论里不断出现“默认值该怎么设”的争论。也有人把 Git 拿来和 Mercurial（另一种分布式版本控制系统）、tarball（源码压缩包）以及 Office 文件格式比较，说明这场讨论早已超出单纯的版本控制本身。
不少人把它当成理解 Git plumbing 的入门或补课材料。有人说自己平时几乎没遇到性能问题，但在把 Git 当作版本化数据库后，才真正理解索引、压缩和历史查询这些细节。也有人读到第二章就学到了多年没弄懂的内部机制，并顺手推荐了《Building Git》这类从零实现 clone 的书。整体看，这部分评论把它当成“读完会更懂 Git”的技术读物。
另一部分评论集中质疑文章质量，认为措辞和结构很像 LLM 生成的模板化文本。有人把正文和站点里的章节片段对照，指出开头和结尾都带有很强的机器腔。也有人直接用“slop”形容它，认为内容像是在 front page 上包装过的自动化产物。这个视角几乎不讨论 Git 本身，而是怀疑作者是否真的在手写这篇文章。
围绕 Git 是否“好用”，评论明显分裂。有人说一旦要面对 bloom filters、packfiles、garbage collector、rerere cleanup 这些内部细节，就会想回到 centralized VCS；也有人反驳说 Git 内部其实很简单，复杂的是用户希望它一键完成所有事情。讨论还扩展到 GitHub（Git 仓库托管平台）是否才是 Git 成为标准的关键，以及 Mercurial、Darcs、CVS、SVN、Perforce、ClearCase、Fossil 等工具的 UX 对比。多数争论的核心不是功能多少，而是“简单可靠的内部结构”和“日常命令是否顺手”之间的取舍。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
评论里也有大量务实的性能经验。Git LFS（Git Large File Storage，大文件外置存储方案）被抱怨会让每次远程操作都更慢，甚至推送时还要反复做硬件密钥认证；有人因此觉得它的运维成本太高，宁愿用 git annex。另一条线则是 `git clone --depth 1` 和 `--filter=blob:none` 这类浅克隆/部分克隆方案，用来减少带宽和磁盘占用，并在需要时再 lazy load 文件内容。反对者提醒，这类优化对 Linux kernel 这种超大协作仓库并不总是合适，默认值必须照顾不同规模的使用场景。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
还有人希望 Git 不只是开发者工具，而是能进入更广泛的工作流。有人设想把 Git 直接整合进 OS 前端，用来管理文档、办公流程甚至个人电脑的时间线历史。围绕源码分发方式，也有人主张默认给 tarball（源码压缩包），把 Git 留给真正要贡献和维护的人；支持 Git 的人则强调它更适合持续更新、打补丁、保留本地修改和 rebase。反对者指出很多办公文件是 binary，但也有人补充 Microsoft Office 文件其实是 zipped XML，未必完全没有版本控制价值。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
LFS（Git Large File Storage）: 把大文件放到仓库外单独存储的扩展，但会增加认证和网络开销。
shallow clone / `--depth 1`: 只克隆最近历史的浅克隆，节省带宽和磁盘，但不适合需要完整历史的大仓库。
partial clone / `--filter=blob:none`: 一种按需拉取 blob 的部分克隆方式，先拿提交和目录，文件内容在需要时再下载。
bloom filter: 一种概率型索引结构，Git 可用它加速历史或路径查询，减少无效遍历。
Mercurial: 另一种分布式版本控制系统，评论里常被拿来和 Git 比较 UX。