40

我正在尝试使用mailmap.filegit 的配置选项。然而，路径不是 shell 扩展的，这意味着我不能写$HOME/.mailmapor ~/.mailmap。如果你正在将你的点文件与类似homesick的东西同步，并且在 Windows、OS X 和 Linux 上使用相同的 .gitconfig，这会很烦人。

我找不到任何 git 的 bugtracker，我不想用类似的东西向 git 邮件列表发送垃圾邮件。我应该如何报告这个错误/轻微的烦恼？

4

3 回答 3

29

正如代码 googlegit-core中提到的（以及Charles Bailey在评论中提到的，它指向git-scm 社区页面）：

可以使用电子邮件地址 git@vger.kernel.org 将 Git 社区的问题或评论发送到邮件列表。错误报告应发送至此邮件列表。

（邮件列表存档在这里）

2020 年第二季度更新，您现在有一个实际的git bugreport命令（见下文末尾）

2015 年更新：最新的参考仍然是Git 社区页面，正如smoothgrips在评论中指出的那样，它提到：

您无需订阅：您将在回复中被抄送。
回复时请保持抄送列表完整（使用“全部回复”）。
灰名单可能会将您的第一篇帖子延迟几个小时。

请注意，邮件服务器将拒绝带有“永久失败”消息的 HTML 消息，因此请使用纯文本。

社区页面还指出“如何有效地报告错误”...

如果您想贡献补丁，请立即前往rtyley/submitgit，它可以帮助您遵循补丁提交流程：

如果您在 上创建拉取请求github.com/git/git/，submitGit可以将其发送到您的邮件列表，正确格式化补丁。
讨论停留在原处——在列表中——但至少第一步要容易一些。

2015 年更新：Git For Windows 现在位于 GitHub ( github.com/git-for-windows)上，并生成最新版本：2.4.2+。
Msysgit 被淘汰，使用msys2 64-bits，并导致git-for-windows.github.io而不是旧的和现在过时的msysgit.github.io。

GitHub 镜像仓库镜像git/git在那里，但不幸的是，它不能用于问题或拉取请求。

2019 年更新：submitGit有一个替代方案：（GitGitGadget）gitgitgadget.github.io，在 Git 2.22（2019 年第二季度）中提到

请参阅Jeff King ( ) 的commit c3a7dd7（2019 年 3 月 12 日）。（由Junio C Hamano 合并 -- --在提交 2d33728中，2019 年 4 月 9 日）peff
gitster

将拉取请求者指向GitGitGadget

在 GitHub 上打开拉取请求的人看到的贡献指南和 PR 模板中，我们提到了该submitGit工具，它提供了一种解决邮件列表的替代方法。
这些天我们也有类似的GitGitGadget工具，我们应该明确表示这也是一种选择。

我们可以继续提及这两种工具，但最好选择其中一种，以免用户选择过多。
毕竟，这里的目的之一是减少首次或不经常贡献者的摩擦。

有几个理由更喜欢GGG：

  1. submitGit似乎仍然有一些粗糙的边缘。例如，它不会使用时间戳来帮助线程式邮件阅读器处理乱序交付。
  2. 主观GGG上，这些天似乎在列表中更常用，尤其是列表常客。
  3. GGG似乎处于更积极的发展中（可能与第 2 点有关）。

所以让我们实际换掉submitGit. 当我们在那里时，让我们在 PR 模板中放置另一个指向该页面的链接，因为这是第一次学习它的用户想要去的地方。阅读更多。GGG
GGG

在 Git 2.25（2020 年第一季度）中，有一个关于对象枚举的教程，它提供了一个关于如何贡献/测试/报告错误的好例子。

请参阅Emily Shaffer ( ) 的提交 e0479fa（2019 年 10 月 11 日）。（由Junio C Hamano 合并——在提交 15d9f3d中，2019 年 11 月 10 日）nasamuffin
gitster

documentation: 添加物体行走教程

签字人：Emily Shaffer
帮助人：Eric Sunshine

现有的关于对象遍历的文档似乎主要是为那些已经熟悉该过程的人提供参考。
本教程试图为几个基本的对象遍历提供入门级指南，以便新的 Git 贡献者可以学习这些概念，而不必费力地通过选项解析或特殊的大小写。

目标受众是刚开始接触对象行走概念的 Git 贡献者。
目标是让这个贡献者准备好能够更容易地理解和修改执行修订游走的现有命令，尽管它也将使贡献者准备好创建执行游走的新命令。

本教程涵盖了对象遍历过程中涉及的结构的基本概述、设置基本提交遍历、设置基本全对象遍历以及为两种遍历类型添加一些配置更改。
它故意不包括如何创建新命令或从命令行或 gitconfigs 搜索选项。

在https://github.com/nasamuffin/git/tree/revwalk有一个相关的补丁集，其中包含本教程生成的代码的参考实现。

注意：该教程已在 Git 2.27（2020 年第二季度）中进行了修改：

请参阅Johannes Schindelin ( ) 的提交 e3f53ce（2020 年 3 月 28 日）。（由Junio C Hamano 合并 -- --在提交 7780604中，2020 年 4 月 22 日）dscho
gitster

MyFirstObjectWalk: 删除不必要的条件语句

签字人：Johannes Schindelin
审核人：Emily Shaffer

在给定的示例中，commitcannot be NULL（因为这是循环条件：如果是NULL，则根本不会输入循环体）。这个开发人员花了一两分钟才发现这是死代码。

让我们删除它，以免让未来的读者感到困惑。

Git 2.25（2020 年第一季度）记录了 GitGitGadget。

请参阅Emily Shaffer ( ) 的commit 3c8d754、commit 3ada78d、commit 4ed5562（2019 年 10 月 31 日）。（由Junio C Hamano 合并——在提交 f089ddd中，2019 年 12 月 1 日）nasamuffin
gitster

myfirstcontrib: 提示找到 gitgitgadget 允许器

签字人：Emily Shaffer

GitGitGadget 是一种方便的工具，用于将针对 Git 的拉取请求转换为 Git-mailing-list-friendly-patch-emails，作为反垃圾邮件，所有新用户都必须/allow由现有用户“编辑”一次，然后才能为新用户执行任何操作用户。

虽然本教程解释了该机制，但它并没有提供太多关于如何寻找允许新拉取请求的人的提示。
因此，请教我们的新 GitGitGadget 用户在哪里寻找可以将他们的名字添加到列表中的人。

此补丁中的建议基于为 GitGitGadget 提出的建议：gitgitgadget/gitgitgadgetPR 138

在 Git 2.25（2020 年第一季度）中，邮件列表归档和 nntp 服务的文档更新。

请参阅Jeff King ( ) 的提交 3eae30e和提交 46c6749（2019 年 11 月 27 日）。（由Junio C Hamano 合并——在提交 3b3d9ea中，2019 年 12 月 6 日）peff
gitster

doc: 用 lore.kernel.org 替换公共收件箱链接

签字人：杰夫·金

由于我们现在正在推荐lore.kernel.org（并且因为该public-inbox.org域最终可能会消失），所以让我们更新我们的内部引用以使用它，也是。
这为我们的参考提供了面向未来的证明，并树立了我们希望人们效仿的榜样。

请参阅“此列表现在也存档于lore.kernel.org/git”

doc: 用 lore.kernel.org 替换 MARC 链接

签字人：Denton Liu

由于我们现在推荐 lore.kernel.org，请将 marc.info 链接替换为 lore.kernel.org。

尽管 MARC 已经存在了很长时间，但没有什么是永恒的（参见 Gmane）。
由于 MARC 使用不透明的消息标识符，切换到 lore.kernel.org 应该是一个严格的改进，因为即使 lore.kernel.org 出现故障，Message-ID 也将允许未来的读者在任何其他存档中查找引用的消息。

我们在其中留下了一个对 MARC 的引用，README.md因为它是供个人阅读的完美邮件存档，而不是用于链接未来的邮件。

和：

RelNotes: 用真实的 Message-ID 替换 Gmane

签字人：Denton Liu

剩下的对 Gmane 的唯一引用是在 RelNotes 中。
尽管这些肯定没有被积极使用，但它们可能对未来的读者具有历史意义，因此让我们确保邮件引用更加健壮。

将指向 Gmane 的链接替换为指向lore.kernel.org（这是我们新的首选邮件列表存档并在 URL 中具有 Message-ID）的链接，并将 Gmane ID 引用替换为 Message-ID。

通过在https://public-inbox.org/git/上搜索“ gmane:<id>”并获取结果消息，可以找到消息 ID。

关于lkml.org：

doc: 用 lore.kernel.org 替换 LKML 链接

签字人：Denton Liu

由于我们现在推荐 lore.kernel.org，请将 LKML 链接替换为 lore.kernel.org。

虽然 LKML 已经存在了很长时间，但没有什么是永恒的（参见 Gmane）。
由于 LKML 使用不透明的消息标识符，因此切换到lore.kernel.org应该是一个严格的改进，因为即使lore.kernel.org出现故障，Message-ID 也将允许未来的读者在任何其他存档中查找引用的消息。

使用 Git 2.26（2020 年第一季度），为新贡献者提供了更多文档。

请参阅Emily Shaffer ( ) 的提交a2dc434 （ 2020 年 2 月 14 日）和提交 4bb4fd4（2020 年 1 月 24 日）。（由Junio C Hamano 合并 -- --在提交 325eb66中，2020 年 2 月 25 日）nasamuffin
gitster

MyFirstContribution: 添加获取帮助的途径

签字人：Emily Shaffer

通过https://lore.kernel.org/git/20191114194708.GD60198@google.com/，我们现在有一个指导邮件列表，我们应该将有问题的新贡献者引导到该列表。

Mention #git-devel，这是针对 Git 贡献者的；寻求帮助以共同获得第一个贡献是该频道的主题。还要提到一些约定，以防人们不熟悉 IRC。

因为导师列表和#git-devel都是 Git 贡献者的子集，所以最后列出主要的 Git 列表并提及一些发布约定。

和：

MyFirstContribution: 改写联系方式

签字人：Emily Shaffer
审核人：Jonathan Nieder

尽量不要阻止新用户向 git@vger.kernel.org 发送问题，并解释指导列表与主列表对比的目的。

对于 Git 2.27（2020 年第二季度），在报告错误之前，请阅读（新）常见问题解答。

请参阅brian m的提交 2149b67（2020 年 3 月 30 日） 。卡尔森 ( bk2204) .
（由Junio C Hamano 合并 -- gitster--在06aaafb 提交中，2020 年 4 月 22 日）

docs: 添加常见问题

签字人：brian m. 卡尔森

Git 是一个非常灵活和强大的软件。

但是，对于许多用户来说，它可能会令人生畏，并且有一组用户经常问的常见问题。

虽然我们已经有了一些新的用户文档，但值得添加一个常见问题解答来解决用户经常遇到的常见问题。

尽管其中一些在文档的其他地方有所提及，但经验表明用户很难找到，因此集中位置很有帮助。

添加这样的常见问题解答并填写一些常见问题和答案。虽然现在条目很少，但我们可以在将来扩展它以涵盖更多内容，因为我们会发现用户提出的新问题。

FAQ 还解决了常见的配置问题，这些问题不仅适用于作为独立软件的 Git，还适用于人们使用的 CI 工具和托管服务提供商的生态系统，因为这些是常见问题的来源。

使用 Git 2.27（2020 年第二季度），您可以使用“错误报告”工具。

请参阅Emily Shaffer ( ) 的提交8f0e984 （ 2020 年 4 月 27 日）和提交 69bcbbc、提交 1411914、提交 617d571、提交 238b439、提交 709df95（2020 年 4 月 16 日）。（由Junio C Hamano 合并 -- --在dd094c2 提交中，2020 年 5 月 1 日）nasamuffin
gitster

bugreport：添加工具以生成调试信息

签字人：Emily Shaffer

教 Git 如何提示用户提供良好的错误报告：重现步骤、预期行为和实际行为。稍后，Git 可以学习如何从存储库中收集一些诊断信息。

如果用户可以向我们发送一份写得很好的错误报告，其中包含我们需要向用户询问的诊断信息，我们可以减少报告者和 Git 贡献者之间的问答往返次数。

如果用户将他们的存储库置于他们感到困惑的状态，他们也可能希望将这样的报告发送给他们当地的“Git 专家”。

git bugreport文档包括：

git bugreport [(-o | --output-directory) <path>] [(-s | --suffix) <format>]

描述

将有关用户机器、Git 客户端和存储库状态的信息以及请求有关用户观察到的行为的信息的表单捕获到单个文本文件中，然后用户可以按顺序共享该文本文件，例如 Git 邮件列表报告观察到的错误。

要求用户提供以下信息：

  • 复制步骤
  • 预期行为
  • 实际行为

在 Git 2.27（2020 年第二季度）中，“ git bugreport”学会了报告存储库中启用的钩子。

请参阅Emily Shaffer ( ) 的提交 788a776（2020 年 5 月 8 日）。（由Junio C Hamano 合并 -- --在提交 3583730中，2020 年 5 月 14 日）nasamuffin
gitster

bugreport：收集已填充的钩子列表

签字人：Emily Shaffer

有时，用户看到的故障可能与正在运行的特定挂钩有关，而用户可能没有意识到。
虽然钩子的内容可能很敏感——包含用户数据或特定于用户组织的进程信息——但只要知道钩子在某个阶段正在运行，就可以帮助我们了解是否出现问题。

如果代码中没有明确的钩子名称列表，我们会从文档中编译我们自己的列表。这可能很容易出现比特腐烂，但是对于错误报告工具的这个小改动来说，为可接受的钩子设计一个单一的事实来源是太多的开销。

在 Git 2.28（2020 年第三季度）中，“ git bugreport”学会了报告正在使用的 shell。

请参阅Emily Shaffer ( ) 的提交 4a4804e和提交 39f4919（2020 年 5 月 12 日）。（由Junio C Hamano 合并——在提交 ce095ec中，2020 年 6 月 9 日）nasamuffin
gitster

help: 添加 shell 路径到--build-options

签字人：Emily Shaffer

如果基于 shell 的 Git 命令失败，了解构建 Git 以尝试指向哪个 shell 可能很有用。
$SHELL_PATH在构建期间设置并用于启动联机帮助页查看器以及 by git-compat-util.h，并在测试期间使用。
' git version --build-options' 鼓励在错误报告中使用，因此在此处包含此信息是有意义的。

和：

bugreport: 包括用户交互外壳

签字人：Emily Shaffer

用户可能会抱怨 Git 与其交互式 shell 交互的方式，例如自动完成或 shell 提示。在这种情况下，了解他们以交互方式使用哪个 shell 对我们很有用。

Git 2.30（2021 年第一季度）已经描述了原始贡献者在回复评论评论后使用补丁更新中的解释的期望。

请参阅Junio C Hamano () 的提交 a6d8d11（2020 年 11 月 20 日）。（由Junio C Hamano 合并 -- --在提交 b94b1f9中，2020 年 11 月 30 日）gitster
gitster

MyFirstContribition: 回答问题不是故事的结局

审核人：Emily Shaffer

评论交流可以从评论者开始询问“你在日志消息（或文档中）中的这个短语是什么意思？”，作者回答了它的意思，然后评论者说“啊，这就是你的意思意思是——那么逻辑的流动是有意义的”。

但这并不是故事的圆满结局。
新的贡献者经常忘记，在上述交流中审查过的材料对于下一个阅读它的人仍然不清楚，直到它得到更新。

当我们在附近时，将用于指代审稿人评论的动词“请求”改写为“建议”——这与同一段落后面出现的“原始”和“建议”之间的对比相匹配，更重要的是更清楚地表明，作者并不是要取悦审稿人的意愿，而是审稿人只是在帮助作者完善他们的提交。提出修改建议，感觉原版更好，或者评论

MyFirstContribution现在在其手册页中包含：

审阅者可能会询问您在补丁集中写了什么，无论是在提议的提交日志消息中还是在更改本身中。您应该在回复消息中回答这些问题，但审阅者询问这些问题以理解您的意图的原因通常是因为您的补丁集需要澄清才能被理解。

不要满足于仅仅在你的回复中回答他们的问题，并听到他们说他们现在明白你想说什么了。更新您的补丁以澄清审阅者遇到的问题，并准备您的 v2；您用来解释 v1 以回答审稿人问题的词语可能有用。你的目标是让你的 v2 足够清晰，这样你就没有必要对下一个阅读它的人给出相同的解释。

localtime()在 Git 2.30（2021 年第一季度）中，已删除了不可重入的使用。

请参阅Taylor Blau ( ) 的提交 4f6460d（2020 年 11 月 30 日）。（由Junio C Hamano 合并 -- --在提交 bb48056中，2020 年 12 月 8 日）ttaylorr
gitster

builtin/bugreport.c: 使用线程安全localtime_r()

签字人：Taylor Blau

为了生成它的文件名，' git bugreport' ( man )内置命令用 ' ' 向系统询问当前时间localtime()。
由于它使用共享缓冲区，因此它不是线程安全的。

即使' git bugreport' ( man )不是多线程的，使用localtime()也会触发一些静态分析工具报错，并且快速

$ git grep -oh 'localtime\(_.\)\?' -- **/*.c | sort | uniq -c

表明线程不安全的“本地时间”的唯一用法是在一个文档中。

因此，将此实例转换为使用线程安全版本以保持一致性，并安抚一些分析工具。

于 2012-05-24T07:45:39.513 回答
3

报告错误的最佳地点通常是邮件列表。您甚至不需要订阅帖子，只需发送电子邮件至：git@vger.kernel.org。

您可以在此处找到有关邮件列表的更多官方信息。

还要检查：

于 2015-03-18T11:45:36.313 回答
1

用于使用git bugreport标准模板撰写电子邮件正文。

Copy-and-paste the generated text file into the email body and send it to git@vger.kernel.org. Be sure to send it as plain text -- HTML will bounce back. (See https://www.dummies.com/software/other-software/10-useful-gmail-settings/ if using GMail).

于 2021-11-30T20:53:20.377 回答