什么是git reflog标识？

Question

在git中，我看到在为git log使用自定义格式时，可能存在“reflog identity”值。什么是reflog身份？

Answer 1

这些是指 reflog条目。 reflog 只是引用更新的记录，而引用本身只是分支和标记名称以及特殊名称的概括HEAD。

Reflog通常在客户端存储库（如您的）上启用，并且通常在服务器存储库上禁用。这自然是可配置的。人们主要用于查看他们的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 <thor@example.com>)
Reflog message: commit: initial torturetest code
Author: A U Thor <thor@example.com>
Date:   Sun Aug 7 01:59:31 2016 -0700

    initial torturetest code

commit 8bb118938b5c6a2978f13e74525b594a48226571
Reflog: HEAD@{1} (A U Thor <thor@example.com>)
Reflog message: checkout: moving from master to torturetest
Author: Someone Else <else@example.com>
Date:   Sat Jul 16 02:00:46 2016 +0200

    Allow backend ...

最近的提交是我昨晚做的（今天早上好）。这是HEAD@{0}。它代表一些提交（其真实名称是以08b87...开头的丑陋的SHA-1哈希）。提交本身有一个作者（我虽然我在这里更改了名称用于显示目的），日期，提交消息等等 - 但是reflog条目HEAD@{0}，也有一个作者（我再次），约会和消息。

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

此reflog条目将 me 作为 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 和分支名称 - 它们指向多个不同的reflog条目中的相同提交。

在我的情况下，例如，我显然在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消息。

² 当使用git log -m -p到拆分合并提交时，此处的例外情况除了reflog本身之外。通常git log完全跳过合并提交，而git show则显示组合差异。 （关于组合差异的文档有点埋没 - 在StackOverflow上搜索术语＆＃34;组合差异＆＃34;。）

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

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

³ 您还可以使用git -c user.name=whatever和git -c user.email=whatever，或者在这种特殊情况下，使用特殊的Git环境变量。使用git -c对于一次性测试尤其方便，如the answer I wrote recently about Git diff color options。

Answer 2

git reflog是另一个命令。

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

“reflog identity”的含义只是：

  

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

Answer 3

请注意，git reflog身份/条目即将更改（2020年，四年后）

使用Git 2.29（2020年第四季度），初步清理refs API，以准备添加新的refs后端“ reftable”。

请参见commit 523fa69的Junio C Hamano (gitster)（2020年7月10日）。
请参见commit de966e3之前的commit ce57d85，commit 9e35a6a（2020年7月10日）和Han-Wen Nienhuys (hanwen)（2020年6月30日）。
^{（由Junio C Hamano -- gitster --在commit 3161cc6中合并，2020年7月30日）}

reflog：清除refs.c层中的邮件

^{签名人：Han-Wen Nienhuys}

关于引荐消息：

• 我们希望reflog消息由一行组成。
  文件后端使用的文件格式可以在消息后添加LF作为分隔符，并通过“ git log -g”之类的命令输出^（man）通过在末尾添加LF来完成这样的不完整行，但是从哲学上讲，终止的LF不是消息的一部分。
• 但是，我们允许refs API的调用者提供NUL终止字节的随机序列。
  在存储消息之前，我们通过将一系列空格压缩为SP并修剪尾随空格来清除呼叫者提供的消息。
  这是我们容忍而不是错误地在其中包含LF的消息（无论是末尾，中间还是两者兼有）的方式。

当前，在写出日志之前，由文件后端完成reflog消息的清除。
使用当前代码就足够了，因为这是唯一写入reflog的后端。
但是可以添加新的后端来编写引用日志，并且无论使用什么后端，我们都希望从“ log -g”中读出的结果日志消息相同，并将代码移动到通用后端层是这样做的一种方式。

另一个好处是，“清理”功能可以在以后独立于各个后端而更新为例如如果需要的话，允许多行日志消息，并且在发生这种情况时，如果从通用层调用清理功能（将被更新），确保我们覆盖所有基础将大有帮助。

旁注：我目前不支持多行reflog消息（没有人要求），但我设想不是将“将大量空格挤入SP和rtrim”清洗，当支持多行和/或逐字记录日志消息的新版Git编写一个新的Git版本时，我们可以在消息 AND 中%urlencode个有问题的字节末尾附加一个SP。刷新记录。
读取端可以最后检测到SP的存在（如果它是由现有版本的Git写入的，应该已经rtrimmed了），作为解码%urlencode恢复原始信号的信号reflog消息。

---

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

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

refs：移动将\t添加到reflog到文件后端的逻辑

^{签名人：Han-Wen Nienhuys}

523fa69c（“ reflog：清除refs.c层中的消息”，2020-07-10，Git v2.29.0-merge）集中化了reflog标准化。
但是，规范化在消息中添加了前导“ \t” 。
这是文件后端中reflog存储格式的产物，因此应在此处添加。

解析引用日志的例程（例如grab_nth_branch_switch）期望消息中不包含“ \t”，因此如果没有此修复程序，git reflog ^{（{{ 3}}）}与reftable不能处理“ @{-1}”语法。