什么是git reflog identity？

Question

在git中，当使用自定义格式化git log时，我看到有可能出现"reflog identity"值。什么是reflog identity？

- Mitar

Answer 1

这些是关于reflog条目的。一个reflog简单地记录引用的更新，而一个引用本身只是分支和标签名称以及像HEAD这样的特殊名称的概括。

Reflogs通常在客户端仓库（例如您的仓库）上启用，并且通常在服务器仓库上禁用。这自然是可配置的。人们最常用于查看其reflog的前端命令是git reflog。如果您愿意，现在可以运行它，但这样做不会帮助解释%ge等内容。因此我们将做一些不同的事情：运行git log -g。

运行git reflog基本上运行git log --oneline -g。通过自己运行git log -g，您可以省略--oneline，从而看到每个reflog条目的多行输出。

输出将类似于以下内容，其中名称和电子邮件地址已更改：

commit 08b876daae9944d1a6fba271cfcd9629c13dfd69
Reflog: HEAD@{0} (A U Thor <[e-mail]>)
Reflog message: commit: initial torturetest code
Author: A U Thor <[e-mail]>
Date:   Sun Aug 7 01:59:31 2016 -0700

    initial torturetest code

commit 8bb118938b5c6a2978f13e74525b594a48226571
Reflog: HEAD@{1} (A U Thor <[e-mail]>)
Reflog message: checkout: moving from master to torturetest
Author: Someone Else <[e-mail]>
Date:   Sat Jul 16 02:00:46 2016 +0200

    Allow backend ...

最近的提交是我昨晚（其实是今天早上）做的，这是HEAD@{0}。它代表某个提交（其真实名称是以08b87...开头的大而丑的SHA-1哈希值）。提交本身有一个作者（我，尽管我在此更改了名称以进行显示），日期，提交消息等等 - 但是reflog条目HEAD@{0}也有一个作者（同样是我），日期和消息。

在这种情况下，提交的作者和reflog作者是相同的。甚至reflog消息基本上与提交主题相同（Reflog message:行只插入了单词commit：）。所以这没有多大帮助 - 但是看一下下一个例子，提交8bb11...。

这个reflog条目将我作为reflog作者，将其他人作为提交作者。¹此外，reflog 消息checkout: moving from master to torturetest与提交的主题行完全不相关，后者以Allow backend开头。

如果您将此与git log -g --oneline或git reflog的短输出进行比较 - 这两个命令都检查HEAD的reflog - 您将只看到reflog消息，以及提交ID和reflog选择器。

这里还有一件值得注意的事情。在常规的git log输出中，每个提交通常²仅出现一次。但是，在git log -g输出中，由于Git正在查看存储在reflog本身中的哈希ID，因此提交可以重复出现。如果您在指向同一提交的不同分支之间来回切换，或使用git reset将分支更改为指向早期指向的提交，或运行git rebase，或执行任何数量的类似操作，您很容易获得引用 - 这适用于HEAD和分支名称。

例如，在我的情况下，我显然在torturetest名称上有些犹豫：

08b876d HEAD@{0}: commit: initial torturetest code
8bb1189 HEAD@{1}: checkout: moving from master to torturetest
8bb1189 HEAD@{2}: checkout: moving from torturetest to master

（我不太确定这是什么——可能只是运行了太多Git命令而忘记在哪个存储库中。 :-)）

回到您的问题：

什么是reflog标识？

这些是存储在每个reflog条目中的名称和电子邮件地址。在私人Git存储库的情况下，在您自己的客户端上，这些可能一直是相同的。但是，由于您可以随时运行git config --global user.name "New User Name"和git config --global user.email new@address来更改它们，³它们可能会有所不同。

---

¹如果你想知道，另一个人也是提交者。提交的作者和提交者以及它们对应的日期和电子邮件地址存储在提交本身中。reflog作者、日期和电子邮件地址存储在reflog条目中。实际上，它今天是一个纯文本文件，因此您可以查看 .git/logs/HEAD 和 .git/logs/refs/heads/master 以查看原始的reflog数据。格式并没有特别好的记录，但是很明显：它具有引用的旧值和新值； reflog的作者、电子邮件和日期戳信息以及reflog消息。

²这里的例外除了reflogs本身之外，还发生在使用git log -m -p来拆分合并提交时。通常git log完全跳过合并提交，而git show会显示它们的组合差异。（组合差异的文档有些深藏不漏——在StackOverflow上搜索术语“组合差异”）。

如果您让git log显示差异，它也可以显示组合差异。在所有情况下，组合差异可能会省略关键信息，因此您可以告诉这些命令做一些不同的事情：对于每个父级合并，生成合并提交树与该特定父级树的差异。这就是-m标志的作用。

当显示从父级＃1到合并提交1234567...的差异时，Git向您显示合并提交信息，然后是差异。然后，在显示从父级＃2到合并提交1234567...的差异时，Git再次向您显示合并提交信息，然后是第二个差异。这就是git log如何多次显示相同提交的方式。

³您还可以使用git -c user.name=whatever和git -c user.email=whatever，或在这种特殊情况下使用特殊的Git环境变量。 使用git -c对于一次性测试非常方便，例如我最近关于Git diff颜色选项的回答.

- torek

---

非常棒的回答！非常感谢！ - Mitar

Answer 2

git reflog 是另一个命令。

每次更改 HEAD，git 都会将其旧值存储在其 .git/log 文件夹中，您可以通过 git reflog 命令查看它们。

“reflog identity”的意思很简单：

每个提交都将按作者和标题分组。

- CodeWizard

Answer 3

请注意，git reflog 的标识/条目即将更改（2020年，4年后）。

随着 Git 2.29（2020年第四季度）的推出，为添加新的引用后端“reftable”做准备，对引用 API 进行了初步清理。

请查看提交 523fa69（2020年7月10日）由Junio C Hamano (gitster)提交。
请查看提交 de966e3，提交 ce57d85（2020年7月10日）和提交 9e35a6a（2020年6月30日）由Han-Wen Nienhuys (hanwen)提交。
^{（由Junio C Hamano -- gitster --合并于提交 3161cc6，2020年7月30日）}

reflog：清理refs.c层中的消息

^{签名作者：Han-Wen Nienhuys}

关于reflog消息：

我们希望reflog消息只包含一行。文件后端使用的文件格式可能在消息后添加LF作为分隔符，并且由诸如“git log -g”之类的命令输出（参见man）可能通过在结尾添加LF来完成这样一个不完整的行，但是从哲学上讲，终止的LF并不是消息的一部分。

但是，我们允许refs API的调用者提供随机的以NUL终止的字节序列。在存储消息之前，我们将压缩空格运行为SP，并修整尾随空格来清理调用方提供的消息。这就是我们容忍而不是出错了有LF的消息（无论是在结尾、中间还是两者兼有）的方式。

目前，reflog消息的清理是由文件后端执行的，在日志写出之前完成。对于当前的代码来说，这已经足够了，因为它是唯一写入reflogs的后端。但是，可以添加新的后端来写入reflogs，无论使用哪个后端，我们都希望从“log -g”读取的结果日志消息都是相同的，将代码移动到通用层是实现这一点的一种方法。

另一个好处是，“清理”函数可以稍后进行更新，独立于各个后端，例如，如果我们想要允许多行日志消息，那么当发生这种情况时，如果通用层调用更新的清理函数，则有助于确保我们覆盖了所有基础。

顺便说一下：我目前不感兴趣支持多行reflog消息（没有人要求），但是我预想到，我们可以将问题字节%urlencode在消息中并附加一个SP，在支持多行和/或原样reflog消息的新版本的Git写入reflog记录时，而不是“压缩空格运行为SP和修整尾随空格”，读取侧可以检测到结尾处存在SP（如果由现有版本的Git编写，则应该已经删除rtrimmed），作为信号表明解码%urlencode可以恢复原始的reflog消息。

---

在 Git 2.29 (2020年第四季度) 中，git reflog 管理其条目的 \t。

请参见 提交 25429fe（2020年7月31日），作者为 Han-Wen Nienhuys (hanwen)。
^{（由 Junio C Hamano -- gitster -- 在 提交 dc3c6fb 中合并，2020年8月1日）}

参考：将添加\t到reflog的逻辑移至文件后端

^{签名：Han-Wen Nienhuys}

523fa69c（"reflog: 清理 refs.c 层中的消息"，2020年7月10日，Git v2.29.0 -- 合并）集中式 reflog 标准化。
然而，标准化在消息前面添加了一个 "\t"。
这是文件后端中 reflog 存储格式的产物，因此应该在那里添加。

解析 reflog 的例程（例如 grab_nth_branch_switch）期望消息中没有 "\t"，因此如果没有这个修复，git reflog^（man） 与 reftable 无法处理 "@{-1}" 语法。

- VonC