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

标签 git data-structures language-agnostic

为了更好地理解 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如何以任意顺序检索和删除元素?

最佳答案

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

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

通常,reflog 条目是简单的线性编号:HEAD@{1}master@{1} 是“HEADmaster 在其最近更新之前指向的提交”,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 本身可能可达或不可达,但它永远不会影响任何其他对象的可达性。)

关于git - git stash 元素存储在哪里?数据结构真的是栈吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42863293/

相关文章:

git - 在 Github 中将 pull 请求 merge 到与默认分支不同的分支

git log - 找出哪个提交添加了特定文件

git - 我不小心用错误的用户帐户推送到了 git 存储库。我怎样才能撤消它或更改用户?

algorithm - 从磁盘查找最长前缀

language-agnostic - 什么是ISO语言?

language-agnostic - 避免硬编码值 IRL 的最佳实践

git - 如何将我的本地 Git 分支名称更改为大写

algorithm - 在 M 天内阅读一本有 N 章的书的最佳方式

java - 单链表清空后仍然消耗内存

c++ - 在 C 中允许重复的 const 限定符但在 C++ 中不允许?