中文翻译：Git Rev News: Edition 1 (March 25th, 2015)-CSDN博客

本文链接：https://blog.csdn.net/weixin_40708226/article/details/134386368

中文翻译：Git Rev News: Edition 1

Git Rev News: Edition 1 (March 25th, 2015)
讨论
其他Git新闻

原文链接：https://git.github.io/rev_news/2015/03/25/edition-1/

Git Rev News: Edition 1 (March 25th, 2015)

欢迎来到第一期的Git Rev News，这是由志愿者们合作撰写的Git相关的所有内容的摘要

我们的目标是以更广泛技术社区可以理解的格式，来针对一些在Git邮件列表上的活动进行聚会和交流。此外，我们还会链接一些我们碰到的有趣的Git相关的文章，工具和项目。

本期汇总了在2015年3月发生的事情。

你可以通过撰写pull request或是创建Issue来对即将发版的Git做出贡献。Git仓库地址

讨论

总览

发展Git开发者 (written by Junio C Hamano)

根据David Kastrup的消息，Christian Couder发起了一场讨论，Michael J Gruber指出，Git开发人员有三类，对于那些没有得到公司赞助的人来说，很难不是作为业余爱好者，而是作为一种获得金钱或建立声誉的途径来开发Git。

在帖子的后面，Christian自愿创办了一个时事通讯（就是当前的Git Rev News）来总结和宣传Git开发人员的作品。同时，著名博客GitMinutes的负责人——Thomas Ferris Nicolaisen，他表示愿意提供帮助。

此外，未来的发布说明将列出新的和有相关回复的Git代码贡献者，并感谢他们对每个发布的帮助。

评审

使git-pull成为内建指令

Paul Tan申请了Git的今年的谷歌夏令营（GSoC），他先于GSoC的开始发送了一个补丁，将git-pull.sh使用C语言重写为的Git内建命令。（译者记：所谓内建命令，就是指在builtin/目录下的以cmd_开头的函数所代表的命令）

事实上，正如GSoC页面中所述：

Git的许多组件仍然是shell和Perl脚本的形式。虽然只要功能能够不断改进，脚本形式一个很好的选择，但它会导致生产代码出现问题，尤其是在多平台兼容性问题上，例如Windows（想想：POSIX到Windows的路径转换问题）。

这就是为什么“将脚本转换为内置”GSoC项目的理念是：

…深入研究Git源代码，将几个shell和/或Perl脚本转换为可移植的高性能C代码，使其成为所谓的“内建命令”。

两位开发人员Duy Nguyen和Stephen Robin似乎已经在过去将git-pull.sh转换为内建命令。这种情况经常发生，所以在开始在Git中开发东西之前，积极搜索和多方询问是个好主意。

Windows Git的开发人员之一Johannes“Dscho”Schindelin感谢Paul在他的补丁中提供了非常详细和经过充分研究的评论，并就这类工作的益处发表了一些评论：

在Windows上，运行时间从8分25秒降至1分3秒。

正是这种速度提升的收益让这个项目如此重要！蒸蚌！

一个更简单但不太完美的策略可能是：在将代码更改为使用内部API之前，使用Duy Nguyen[2]建议的run_command*()函数，直接将shell脚本逐语句转换为C。

这个想法有一个直接的策略，以尽可能高效的方式转换脚本。如果第一步是对基于run_command*()的内建函数进行逐句代码的转换，那么代码评审也会变得更容易。
此外，拥有能及时完成的简明步骤也是有意义的。

对于测试套件，Matthieu Moy建议：

理想情况下，我认为解决方案是改进测试套件，使其尽可能全面，但编写一个全面的测试套件可能过于耗时。

虽然这么做很耗时，但也非常有益，因为代码最终会得到更好的测试。当然，重新代码很容易会让已经成熟的成品彻底破碎，因为无论何时，任何未经测试的东西都很容易被攻破。
我建议做一些手动突变测试：针对你的C代码注释几行代码，看看测试是否仍然通过，如果通过了，想办法添加一个未注释时会失败的测试，一旦你取消注释代码，它就会再次通过。

禁止git log中–graph、–no-walk两个选项的同时使用

Dongcan Jiang今年可能也会申请成为Git的GSoC学生，他发送了一个补丁，阻止命令git log中两个选项--graph和--no walk一起使用。他之所以发送这个补丁，是因为Git社区要求即将参加GSoc的学生参与一个微项目，以确保他们能够与社区正常合作。

Eric Sunshine提出了一些很好的常见的建议，这些建议经常在即将到来的补丁中提出：

禁止git log中–graph/–no-walk两个选项的同时使用

样式：在subject:line这样的模式中不要使用大写字母。在前缀中加上要修改的命令或模块，后跟冒号。例如：
log: forbid combining –graph and –no-walk
或者像这样：
revision: forbid combining –graph and –no-walk

因为–graph是连通的提交记录，而–no-walk是关于离散的提交记录。

好，你可能也想提及更广泛的讨论，请查看commit中的描述信息：

revision.c: Judge whether --graph and --no-walk come together when running git-log.
buildin/log.c: Set git-log cmd flag.
Documentation/rev-list-options.txt: Add specification on the forbidden usage.

这样的描述信息比在文章中重复补丁能更加清晰简洁表达补丁的内容。（译者记：因此，commit中的描述信息非常重要）
此外，这种变化应该伴随着新的测试。

RenéScharfe和Junio也提出了一些改进，特别是在代码方面。

Junio还根据给出的论据解释了git show的有趣行为：

当“git-show”被赋予一个范围时，它将"no-walk"关闭，并成为一个和连通历史的命令。否则，它就是一个关于离散提交历史的命令。

一场关于打破“&&-链”的纷争 (written by Junio C Hamano)

我们经常看到测试脚本上的评论指出&&-链中的断裂，这到底是什么意思？
假如你写了如下一个测试代码

test_expect_success 'frotz and nitfol work' '
	git frotz
	git nitfol
'

这样的代码错误在于，即使frotz命令以非零错误状态退出，测试框架也不会检测到。测试必须这样写：

test_expect_success 'frotz and nitfol work' '
	git frotz &&
	git nitfol
'

Jeff重新提出了一个聪明的想法，该想法由Jonathan Nieder于2013年10月首次提出，就是为了在自动检测此类问题。其想法是尝试运行带有以下前缀的魔术字符串的测试代码：(exit 117) &&。如果在测试中所有的东西都与&&正确地链接在一起，那么运行这样的测试将以错误代码117退出（重要的假设是错误代码在其他地方未使用）。另一方面，如果出现&&链的中断，则以魔术字符串为前缀的测试要么成功，要么失败，退出代码则一定不会是117。（译者记：原因是，如果&&链中断，程序退出代码将是最后一条shell语句的退出代码，而同exit 177链接成功的shell语句执行结束后的退出代码则会被最后一条shell语句的退出代码所覆盖。）

他的这项工作发现了许多真正的测试代码中的漏洞，但幸运的是，没有发现正在测试的命令失败;-)（译者记：真是万幸，不然如果测试代码失败，意味着可能出现许多bug，这个调bug还是比较恶心的）

由于每个开发人员可以访问的平台的多样性以及每个开发人员在这些平台上测试Git的时间不可避免地受到限制，Jeff没有运行的一些测试中的&&断链预计会被其他人抓住。几天后，Torsten Bögershausen在一个只在不区分大小写的文件系统上运行的测试中确实发现了一个。（译者记：译者写Git测试代码时，也会时常出现断链的bug，看来很多大佬也会遇到hhh）

支持

Git with Lader logic

人们经常在Git邮件列表中询问他们是否可以使用Git来管理特殊内容。幸运的是，邮件列表由不同领域的许多专家监控，他们通常可以提供具体的答案。（译者记：不愧是知名开源项目，还得是你=。=）

这次Bharat Suvarna询问PLC程序

Kevin D 给出了寻常但并不具体的答案：

虽然git对内容不是很挑剔，但它经过了优化，可以跟踪文本文件。像显示diff和合并文件这样的事情只适用于文本文件。
Git可以跟踪二进制文件，但也有一些缺点：

Diff/Merge工作不正常
文件压缩通常很困难，因此存储库的大小可能会随着存储内容的大小而增加

然后Randall S. Becker给出了一个更具体的答案：

许多PLC程序要么以XML、L5K或L5X、TXT、CSV或其他文本格式存储其项目代码，要么可以导入和导出为文本形式。如果你有一个代表你的项目的目录结构，并且文件格式有合理的行分隔符，这样可以很容易地进行diff，那么git很可能会适合你。如果您的工具有问题或.gitignore，您不必将本地.git存储库与您的工作区放在同一目录中。您可能需要使用GUI客户端来管理本地存储库并处理commit/push/pull/merge/rebase功能，因为我预计您使用的任何PLC系统都没有内置git。

Doug Kelly还提供了一些有趣的具体信息，并指出了一个网站的更多信息。

感谢大家提供的这些有用的答案！

其他Git新闻

开发人员

David Kastrup（dak at gnu.org）在2.1.0版本中重新实现了“git blame”的重要部分，因为它通过复杂的历史记录和大文件获得了巨大的性能提升。由于从事自由软件工作是他的唯一收入来源，如果你觉得这种改进有用，请考虑为他的薪酬贡献力量。（译者记：不愧是知名开源项目，还得是你=。=）

事件

Git Merge 2015，Git社区会议，将于2015年4月8日和9日在法国巴黎举行，感谢GitHub和赞助商。如果你是一名Git开发人员，需要旅行或其他帮助，请联系Peff，又名Jeff Kingpeff@peff.net。

发布

Git v.2.3.2，3月6日。

最新的维护版本Git v2.3.2现在可以在通常的地方使用。

命令行GUI工具tig 2.1版，3月11日：

我刚刚发布了Tig的2.1版本，它带来了很多改进，以加快在大型存储库（如Linux内核回购）中的使用速度（请参阅与#310、#324、#350和#368相关的改进）。除此之外，这个版本带来了全面的小改进，并修复了相当多的错误。

NodeGit 0.3.0，3月13日：

更新至libgit2 v0.22.1。此版本包含中断的API更改。最值得注意的是身份验证过程中如何处理证书错误的更改。
有关更多详细信息，请查看更改日志：http://www.nodegit.org/changelog/#v0-3-0

Git v2.3.3，3月14日：

最新的维护版本Gitv2.3.3现在可以在通常的地方使用。自v2.3.2以来，它由26个非合并提交组成，由11人贡献，其中1人是新贡献者。

Git v2.3.4，3月23日：

最新的维护版本Gitv2.3.4现在可以在通常的地方使用。自v2.3.3以来，它由22个非合并提交组成，由9人贡献，其中1人是新面孔。所有这些修复都已经在“master”分支中存在了一段时间。

来自邮件列表之外

谷歌代码宣布关闭，为所有剩余的项目提供了迁移到Git/GitHub的便利。
Nava Whiteford写了一篇关于最常见的Git错误/问题和解决方案的热门文章。
一个古老但相关的资源：Git的飞行规则。
Git《Git in Practice》一书作者Mike McQuaid的访谈。
说到Git书籍，有一本新书即将问世：Git Essentials。
还有一个关于掌握Git的新视频课程。作者刚刚在本文中接受了采访…=。=。
播客GitMinutes的最新一集，关于掌握Git。
这里有一个Git Hook，它将自动将新的TODOs转换为问题跟踪器中的任务（如果您使用GitHub问题）。
GitLab和BitBucket最近都发布了关于最近OpenSSL漏洞的公告。请确保您的Git或其他基于OpenSSL的服务不受影响！

文章参与人

本期Git Rev News由Christian Couder策划christian.couder@gmail.com和Thomas Ferris Nicolaisentfnico@gmail.com在Junio Hamano、Matthieu Moy、Jeff King、David Kastrup、Stefan Beller和Alex Vandiver的帮助下。