git - git stash 元素存储在哪里？数据结构真的是栈吗？

Question

为了更好地理解 git stash，我想知道: git stash 的元素存储在哪里以及存储在什么数据结构中？在堆栈中？在有序集合中？

细节:

每个文档、文章和书籍(除了 Git Internals )都说 git stash 是一个 堆栈 .

最近，我发现您可以从存储中以任意顺序检索和删除元素——多么有用的功能。由于此功能和 A Hacker's Guide to Git ，在我看来， stash 更像是一个 按时间顺序排列的引用文献集 某处。然而，在 .git/refs/stash仅以 merge 提交的形式存储最新的 stash 元素(它还包含创建 stash 元素的日期)。

是否有另一个( top-secret pre-index stash-cache ;)数据结构保存所有存储元素？或者 git stash (list|pop|apply) 是否从其常规对象存储中检索元素？如何？

那么 stash 元素形成什么数据结构呢？元素的时间顺序是否由 merge 提交的日期隐式给出？如果元素实际上存储在堆栈中，那么git如何以任意顺序检索和删除元素？

Answer 1

作为 ElpieKay wrote in a comment ，除了当前存储之外的所有内容都存储在引用 refs/stash 的 reflog 中。请参阅 the gitglossary 中“ref”和“reflog”的定义。请注意，像 master 和 develop 这样的分支名称是一种引用，分别是全名 refs/heads/master 和 refs/heads/develop 的缩写。标签名是另一种引用；标签 v2.2 实际上是引用 refs/tags/v2.2 。

大多数引用都以 refs/ 为前缀。事实上，各种 HEAD—— HEAD 本身，以及 MERGE_HEAD 、 CHERRY_PICK_HEAD 、 ORIG_HEAD 等等——是唯一的异常(exception)，其中大部分没有引用日志。 HEAD 是唯一一个这样做的。

通常，reflog 条目是简单的线性编号:HEAD@{1} 或 master@{1} 是“HEAD 或 master 在其最近更新之前指向的提交”，master@{2} 是两个步骤前的提交，依此类推。这在 gitrevisions 中有描述。为方便起见，可以使用 @{0} 引用当前值:master@{0} 和 master 始终解析为相同的哈希 ID。如果 refs/stash 引用以与其他引用相同的方式使用，它将作为队列而不是堆栈工作——但它不是那样使用的。相反，git stash 代码显式删除早期条目。

由于编号始终是连续的，删除一个条目会导致所有较高的数字下降一。例如，如果您手动删除 master@{5} ，那么曾经是 master@{6} 的现在是 master@{5} ，曾经是 master@{7} 的现在是 master@{6} ，等等。

当然，添加新条目会将所有内容推高。因此，当您创建一个新的存储时，曾经是 stash 又名 stash@{0} 的存储现在是 stash@{1} 。曾经是 stash@{1} 的那个现在是 stash@{2} ，依此类推。对于其他 reflogs，比如 master ，没有人称之为“推送”，它只是普通的队列在起作用。

但是，一旦您删除了 stash@{0} 又名 stash ，所有更高的条目—— stash@{1} 、 stash@{2} 等等——都下降了一个，所以现在 stash 已被“pop ”，之前的 stash@{1} 只是 stash 。当然，您也可以 git stash drop stash@{4} 删除该特定条目，保留 0 到 3 并重新编号 5 及以上。请注意，任何特定存储的 git stash pop 仅表示“应用，如果似乎成功，则删除”。

请注意，并非完全偶然，每个 reflog 条目还附加了一个时间戳。您可以编写 master@{yesterday} 或 master@{3.hours.ago}，Git 将根据时间戳找到适当的 reflog 条目的哈希 ID。1 因为存储标识符只是 reflog 条目，因此相同的语法在那里起作用。 (我从来没有真正发现这一切在任何地方都有用，也许是因为我在工作时没有时间感，不记得现在是一周中的哪一天，更不用说我早些时候做的事情了。:-))去使用这些时间戳，大多数 reflog 都会过期:默认情况下，旧的 reflog 条目将在 90 天后消失，如果无法从同一引用的当前值访问它命名的对象，则仅在 30 天后消失。2 但是，refs/stash 本身默认情况下，免除此过期时间。所有这些都是可配置的:查看 the gc.reflogExpire documentation 中的所有 git config 设置。

1如果您在一天内多次更新引用，但每小时不超过一次，则 @{yesterday} 表示 @{24.hours.ago} 。如果每小时更新一次以上，再乘以 60: @{1440.minutes.ago} 。如果每分钟更新一次以上，再次乘以 60: @{86400.seconds.ago} 。分辨率并没有比这更好。

2这就是 Git 保留 30 天，但最终清除旧提交的方式，例如被 git rebase 放弃的提交。可达性是由存储库中的标签、提交和树对象形成的有向无环图或 DAG 提供的一个关键概念。 (Blob 在 DAG 中但不参与扩展，因为它们始终是叶节点。因此 Blob 本身可能可达或不可达，但它永远不会影响任何其他对象的可达性。)