19

免责声明：这个问题纯粹是信息性的，并不代表我遇到的实际问题。我只是想弄清楚一些事情（因为我喜欢弄清楚事情，我知道你也这样做）。

所以我在玩 git，试图让修改后的提交过期。我的 reflog 看起来像这样：

4eea1cd HEAD@{0}: commit (amend): amend commit
ff576c1 HEAD@{1}: commit: test: bar
5a1e68a HEAD@{2}: commit: test: foo
da8534a HEAD@{3}: commit (initial): initial commit

这意味着我做了两次提交（da8534a和5a1e68a），然后是ff576c1我修改的第三次提交4eea1cd。

不出所料，我的git log样子是这样的：

* 4eea1cd (HEAD, master) amend commit
* 5a1e68a test: foo
* da8534a initial commit

根据我（尽管我）对提交到期的了解，有一天（很可能，默认情况下在 30 天内）git gc应该收集ff576c1. 现在我不想等待 30 天才能看到这种情况发生，所以我开始运行一些命令，首先：

git fsck --unreachable --no-reflogs

正如预期的那样，这给了我：

unreachable blob 5716ca5987cbf97d6bb54920bea6adde242d87e6
unreachable tree 1e60e555e3500075d00085e4c1720030e077b6c8
unreachable commit ff576c1b4b6df57ba1c20afabd718c93dacf2fc6

所有人都确信我将结束那个可怜的孤独ff576c1提交，然后我运行git reflog expire：

git reflog expire --dry-run --expire-unreachable=now --all

那个时候，给了我：

would prune commit: test: bar
would prune commit (amend): amend commit

起初我虽然 myHEAD没有引用master，但正如您在git log我之前给出的输出中看到的那样，它确实如此。此外，cat .git/HEAD确认（大喊ref: refs/heads/master）。无论如何，即使这很愚蠢，因为4eea1cd是我master分支的负责人。

所以我在这里，很困惑这两个命令不会给我相同的提交，并且想知道地狱怎么4eea1cd可能无法访问，因为它是我master分支的实际尖端。

知道发生了什么吗？

编辑：我只是注意到如果我将--rewrite选项添加到git reflog expire，就像这样：

git reflog expire --dry-run --expire-unreachable=now --all --rewrite

然后我只得到修改后的提交：

would prune commit: test: bar

我还是不明白，因为根据git help reflog：

   --rewrite
       While expiring or deleting, adjust each reflog entry to ensure that
       the old sha1 field points to the new sha1 field of the previous
       entry.

在我的情况下这没有意义。好吧，至少我不明白，因为显然它确实改变了一些东西。

4

1 回答 1

12

这种行为来自 reflog 设计理念和垃圾收集需求之间的交互。

为了让垃圾收集器安全地删除提交，必须删除对该提交的所有引用——包括 reflog 条目中的引用。尽管有reflog show. 为了确保安全的垃圾收集，reflog expire只需删除两个 SHA1 之一标识无法访问的提交的任何条目。

在您的情况下，最新 reflog 条目的更改前值是指无法访问的提交。即使由 post-change 值标识的提交仍然可以访问，也会reflog expire删除该条目。

这种设计易于实现，并导致不完整但准确的日志。

--rewrite选项_

不幸的是，删除引用仍然可访问的提交的条目有几个问题：

  • 日志中留下一个空白
  • 与仍然可访问的提交相关的有用信息丢失

该--rewrite选项通过以下方式更改行为来解决这些问题：

  • 和以前一样，由更改后 SHA1 标识的提交无法访问的条目将被删除。
  • 修改前更改提交不可达的条目以弥合已删除条目留下的间隙（更改前 SHA1 设置为前一个条目的更改后 SHA1 的值）。

不幸的是，修改条目会导致日志不再准确反映 ref 的历史记录。例如，更改原因可能在重写后不再有意义。这就是为什么--rewrite不是默认值。

于 2012-02-11T00:19:49.293 回答