git
中,当使用自定义格式化git log
时,我看到有可能出现"reflog identity"值。什么是reflog identity?git
中,当使用自定义格式化git log
时,我看到有可能出现"reflog identity"值。什么是reflog identity?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 <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}
也有一个作者(同样是我),日期和消息。Reflog message:
行只插入了单词commit:
)。所以这没有多大帮助 - 但是看一下下一个例子,提交8bb11...
。checkout: moving from master to torturetest
与提交的主题行完全不相关,后者以Allow backend
开头。git log -g --oneline
或git reflog
的短输出进行比较 - 这两个命令都检查HEAD
的reflog - 您将只看到reflog消息,以及提交ID和reflog选择器。git log
输出中,每个提交通常2仅出现一次。但是,在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
来更改它们,3它们可能会有所不同。
1如果你想知道,另一个人也是提交者。提交的作者和提交者以及它们对应的日期和电子邮件地址存储在提交本身中。reflog作者、日期和电子邮件地址存储在reflog条目中。实际上,它今天是一个纯文本文件,因此您可以查看 .git/logs/HEAD
和 .git/logs/refs/heads/master
以查看原始的reflog数据。格式并没有特别好的记录,但是很明显:它具有引用的旧值和新值; reflog的作者、电子邮件和日期戳信息以及reflog消息。
2这里的例外除了reflogs本身之外,还发生在使用git log -m -p
来拆分合并提交时。通常git log
完全跳过合并提交,而git show
会显示它们的组合差异。(组合差异的文档有些深藏不漏——在StackOverflow上搜索术语“组合差异”)。
如果您让git log
显示差异,它也可以显示组合差异。在所有情况下,组合差异可能会省略关键信息,因此您可以告诉这些命令做一些不同的事情:对于每个父级合并,生成合并提交树与该特定父级树的差异。这就是-m
标志的作用。
当显示从父级#1到合并提交1234567...
的差异时,Git向您显示合并提交信息,然后是差异。然后,在显示从父级#2到合并提交1234567...
的差异时,Git再次向您显示合并提交信息,然后是第二个差异。这就是git log
如何多次显示相同提交的方式。
3您还可以使用git -c user.name=whatever
和git -c user.email=whatever
,或在这种特殊情况下使用特殊的Git环境变量。 使用git -c
对于一次性测试非常方便,例如我最近关于Git diff颜色选项的回答.
git reflog
是另一个命令。
每次更改 HEAD
,git 都会将其旧值存储在其 .git/log
文件夹中,您可以通过 git reflog 命令查看它们。
“reflog identity”的意思很简单:
每个提交都将按作者和标题分组。
请注意,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消息:在 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}
" 语法。