期待 Git 2.56 —— 以及 3.0
关于 Git 2.56 和未来的 3.0 的计划引发了广泛讨论，焦点在于如何从 SHA‑1 迁移到 SHA‑256 而不破坏历史、工具链或签名，以及如何在迁移期间验证完整性。评论者还在权衡：为更安全的内部实现引入 Rust 的利弊；采用 reftable 和可插拔后端等新存储机制，替代基于文件系统的 refs；以及改进长期存在的易用性问题，如冲突样式、默认值和对 change ID 的支持。讨论也延伸到更广泛的安全问题，包括哈希选择与量子威胁的关系，以及在大型 C 代码库中渐进式改动是否能真正提升安全性。
SHA-256 迁移与历史重写
- 多条评论讨论从 SHA-1 迁移到 SHA-256 是否需要强制推送和历史重写。
- 担忧包括：强制推送期间历史篡改风险；在 issue、评论和代码中基于 SHA 的引用失效；浅克隆失效；现有提交签名失效。
- 有人指出内容 blob 并不会改变，因此可以重新哈希并比较 SHA-1 与 SHA-256 的历史，但这并不能阻止历史损坏。
- 也有人强调，Git 不会自由混用 SHA-1 和 SHA-256 仓库（例如子模块），这意味着长期并存的双仓库方案和映射表。
- 文档显示，这一变化更像是带有兼容层和查找表的重打包，而不只是一次硬切换。
Git 中采用 Rust
- 一方认为 Rust 被不必要地“强推”，而且只占很小一部分的 Rust 代码并不会实质提升安全性。
- 另一方回应：
- 渐进式改进很重要，尤其对新代码和解析器而言，因为 C 在内存安全漏洞方面有很长的 CVE 历史。
- 对新组件使用更安全的语言是合理的，即使遗留 C 代码仍然保留。
- 讨论中还提到其他“安全 C”方案（例如 Fil-C），并指出其在性能和内存方面存在权衡。
存储后端、refs 与 reftable
- 有人希望 Git “抛弃慢文件”，改用“真正的数据库”。
- 反方观点：文件系统本身就是一种非关系型数据库；性能问题主要来自新的使用场景（大量 refs、hub 风格工作流）。
- 目前正在推进可插拔后端（用于 refs 的 reftable；以及 SQLite、S3 等替代对象存储）。
- Reftable 因解决 ref 名称/路径问题和大小写敏感问题而受到赞赏，但与工具链（如 libgit2、shell 集成）的兼容性是一个担忧。
默认值、UX 与工作流功能
- 有人希望 Git 3.0 修复“糟糕的默认值”，包括：
- 更安全的推送默认值（
--force-with-lease、自动远程设置）。 - 更好的冲突样式（
zdiff3）、改进的子模块 diff 与递归、以及默认启用rerere。
- 更安全的推送默认值（
- 也有人主张为提交引入标准化的“change ID”（如 Gerrit、jj、GitButler 所用），以支持按提交审查、堆叠式变更，以及在 rebase 后保持稳定 ID；当前 Git 命令往往会丢弃这类头部信息。
- 关于“简单快照”的不同看法：使用
git stash、专门的 WIP 分支/标签，或者外部快照工具。
安全与量子问题
- 讨论澄清：
- 长度扩展攻击与 Git 对哈希的使用方式无关。
- 量子威胁主要影响非对称密码；对称密码和哈希最多只会遭受平方根级别的安全性削减。
- SHA-256 被认为已经足够；在已进行多年迁移工作的情况下，现在切换到 SHA-3 被视为不切实际。
其他
- 提到 GitHub 和 Bitbucket 在 SHA-256 支持方面仍然滞后，不过据说 GitHub 有私有预览。
- 也有人对 reftable 成为默认选项感兴趣，并顺带讨论了整数型提交 ID（如 Mercurial 中的做法）以及影响 refs 的文件系统崩溃行为。