Looking forward to Git 2.56 - and 3.0
Looking forward to Git 2.56 - and 3.0
展望 Git 2.56 与 3.0
The Git source-code management system is at the core of development processes worldwide, so changes, especially incompatible changes, are of great interest to the developers involved. The Git 2.56 release, which can be expected around the end of September, is currently available in release-candidate form. It is not the most earth-shaking of releases, but the one that follows, which might be the long-awaited Git 3.0, may well be.
Git 源代码管理系统是全球开发流程的核心，因此其变更，尤其是那些不兼容的变更，备受开发者关注。预计于 9 月底发布的 Git 2.56 版本目前已进入候选发布（release-candidate）阶段。虽然这并不是一个惊天动地的版本，但紧随其后的版本——即人们期待已久的 Git 3.0——很可能会带来重大变革。
What’s in Git 2.56
Git 2.56 有什么新内容？
The Git 2.56 release contains something over 700 non-merge commits; it brings a number of nice improvements, but will not fundamentally change the Git experience for most users. One feature that offers some potential in that regard is the addition of the drop subcommand to the (still experimental) git history toolbox: $ git history drop commit-id. This command will cause the identified commit to be removed from the history of the current branch, replaying all commits that were added after it. It offers an easier way of removing an offending commit. Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories.
Git 2.56 版本包含了 700 多个非合并提交；它带来了一些不错的改进，但不会从根本上改变大多数用户的 Git 使用体验。其中一个具有潜力的功能是为（仍处于实验阶段的）git history 工具箱增加了 drop 子命令：$ git history drop commit-id。该命令会将指定的提交从当前分支的历史记录中移除，并重放其后添加的所有提交。它提供了一种更简便的方法来移除有问题的提交。遗憾的是，如果历史记录中包含合并提交，该命令仍无法工作，这使得它在许多（或大多数）仓库中无法使用。
The git status command will now suggest a git pull command to update a branch that is behind the branch it tracks. It still, though, will say that a branch is “up to date” even if it lags behind an (unfetched) remote tracking branch. The git refs command exists to manipulate references at a low level; in 2.56, it has gained a number of new subcommands. Those commands, create, delete, update, and rename, perhaps surprisingly for Git, do exactly what their names suggest they would.
git status 命令现在会建议使用 git pull 来更新落后于其跟踪分支的分支。不过，即使分支落后于（未获取的）远程跟踪分支，它仍然会显示分支为“up to date”（最新）。git refs 命令用于在底层操作引用；在 2.56 版本中，它增加了一些新的子命令。这些命令——create、delete、update 和 rename——正如其名，执行的功能非常直观，这在 Git 中或许令人感到意外。
There are a number of minor usability tweaks. The new --delete-merged option to git branch will remove local branches that have been merged into their remote tracking branches. An attempt to delete a branch with git branch -d will fail, with a useful message, if that branch is being used for bisection. Attempts to lock the configuration file will be retried on failures, avoiding annoyance when multiple commands try to modify the file at once. git add has a new --resolved option that only adds files with merge conflicts that have been resolved. Beyond that, there is the usual long list of bug fixes, refactorings, and performance improvements. All told, 2.56 looks like a solid release, but it also shows the signs of a project that is holding back much of its more significant work for the future. That leads to the question of what comes next.
此外还有一些小的可用性调整。git branch 的新选项 --delete-merged 可以删除已合并到其远程跟踪分支的本地分支。如果某个分支正在进行二分查找（bisection），尝试使用 git branch -d 删除它将会失败，并给出有用的提示信息。当锁定配置文件失败时，系统会自动重试，从而避免了多个命令同时修改文件时带来的困扰。git add 增加了一个新的 --resolved 选项，仅添加已解决合并冲突的文件。除此之外，还有一长串常规的错误修复、重构和性能改进。总而言之，2.56 看起来是一个稳健的版本，但也显示出该项目正在为未来积蓄更多重大变革的迹象。这就引出了下一个问题：接下来会发生什么？
After 2.56?
2.56 之后？
In early September, Git maintainer Junio Hamano asked the community what the next release should be. Would it be best to put out the 3.0 release that the community has been working toward for some time, finishing the year on a high note? Or, instead, is there a need for one or more 2.x releases still before the 3.0 release can happen? This is an important question, because 3.0 will contain a number of compatibility breaks that may make some users pause before upgrading.
9 月初，Git 维护者 Junio Hamano 向社区询问下一个版本应该是什么。是应该发布社区期待已久的 3.0 版本，为今年画上圆满的句号？还是在 3.0 发布之前，还需要一个或多个 2.x 版本？这是一个重要的问题，因为 3.0 将包含一些不兼容的变更，可能会让一些用户在升级前犹豫不决。
Of those, perhaps the most significant is the switch to using the SHA-256 hash function by default, rather than the SHA-1 hash that Git has used since the beginning. SHA-1 has long been deemed to be weak, which is worrisome for applications like Git. Hashes are used to identify every object (files, directory trees, commits) in the Git repository, and are used to verify the chain of commits leading to any given point. If SHA-1 can be broken, it can conceivably be used to modify the history of a repository in ways that are difficult or impossible to detect.
其中最重大的变更或许是默认使用 SHA-256 哈希函数，而不是 Git 自诞生以来一直使用的 SHA-1 哈希。SHA-1 长期以来被认为存在弱点，这对于像 Git 这样的应用来说令人担忧。哈希值用于标识 Git 仓库中的每个对象（文件、目录树、提交），并用于验证通往任何给定点的提交链。如果 SHA-1 被破解，理论上可以用来以难以察觉或无法察觉的方式修改仓库历史。
Git has long included defenses against the known SHA-1 attacks, and few people appear to be seriously worried about the potential for compromised repositories now. Still, it makes a lot of sense to move to a more secure hash function. Non-experimental support for SHA-256 has existed in Git since the 2.42 release in 2023, though some of the glue for interoperating with older repositories has taken longer. The biggest concern that has kept the Git developers from moving to SHA-256 by default for some time now has been support (or the lack thereof) at the major forge sites. GitLab has had support since 2024, and Forgejo has support as well. The elephant that is still missing from this room, though, is GitHub; releasing a version of Git that creates GitHub-incompatible repositories is a worrisome prospect.
Git 长期以来一直包含针对已知 SHA-1 攻击的防御措施，目前似乎很少有人真正担心仓库被破坏的可能性。尽管如此，转向更安全的哈希函数是非常合理的。自 2023 年 Git 2.42 版本发布以来，Git 就已经提供了非实验性的 SHA-256 支持，尽管与旧仓库互操作的一些衔接工作花费了更长时间。长期以来，阻碍 Git 开发者将 SHA-256 设为默认选项的最大担忧是各大代码托管平台的支持情况。GitLab 自 2024 年起已提供支持，Forgejo 也同样支持。然而，房间里仍然缺少的那头“大象”是 GitHub；发布一个会创建与 GitHub 不兼容的仓库的 Git 版本，是一个令人担忧的前景。
It still is not clear when GitHub might add that support, but it is notable that brian m. carlson, a GitHub employee and a key developer behind the SHA-256 transition, responded to Hamano’s question by saying that news on that topic was coming, and that having the next release be 3.0 might be the best choice. That said, carlson has posted one other change that they would like to see added before 3.0 comes out. While Git has always managed hexadecimal numbers (specifically, object IDs) as lower-case strings, it has also accepted upper-case IDs. That leads to situations where two seemingly different IDs (f00f00 and F00F00, say) are actually the same. Seemingly, bugs and security vulnerabilities have arisen from this ambiguity. So carlson wants to change Git’s behavior to only accept IDs in lower case. That is a change that, seemingly, should not cause problems for too many users, but there is almost certainly somebody somewhere who relies on that behavior. Another significant change that has been waiting for the 3.0 release is the switch to the “reftable” mechanism. A reference (more commonly “ref”) in Git is an association between a name and an object in the repository; branches, tags, and remotes are all refs, for example. Git currently (by default) stores each ref as a file under .git/refs/ in…
目前尚不清楚 GitHub 何时会增加该支持，但值得注意的是，GitHub 员工、SHA-256 转换背后的关键开发者 brian m. carlson 在回应 Hamano 的问题时表示，相关消息即将发布，并且将下一个版本定为 3.0 可能是最好的选择。话虽如此，carlson 还提出了另一个他希望在 3.0 发布前加入的变更。虽然 Git 一直将十六进制数字（特别是对象 ID）作为小写字符串处理，但它也接受大写 ID。这导致了某些情况，即两个看似不同的 ID（例如 f00f00 和 F00F00）实际上是同一个。显然，这种歧义已经引发了一些错误和安全漏洞。因此，carlson 希望改变 Git 的行为，使其仅接受小写 ID。这个变更看起来不会给太多用户带来问题，但几乎可以肯定，在某些地方一定有人依赖这种行为。另一个等待 3.0 版本发布的重大变更是转向“reftable”机制。Git 中的引用（通常称为“ref”）是名称与仓库中对象之间的关联；例如，分支、标签和远程仓库都是引用。目前，Git（默认）将每个引用存储为 .git/refs/ 下的一个文件……