何时会进行git对象修剪：为什么“git gc”不删除提交？

Question

何时会进行git对象修剪：为什么“git gc”不删除提交？

18

我正在制作一门Git课程，想要提到失去的引用在运行git gc之前并不是真正的丢失。但事实并非如此。即使在运行git gc --prune=all --aggressive之后，这些失去的引用仍然存在。

显然，我理解错了什么。在课程中说错话之前，我想搞清楚事实！下面是一个示例脚本，说明了这种效应：

 #!/bin/bash

 git init

 # add 10 dummy commits
 for i in {1..10}; do
     date > foo.txt
     git add foo.txt
     git commit -m "bump" foo.txt
     sleep 1
 done;

 CURRENT=$(git rev-parse HEAD)
 echo HEAD before reset: ${CURRENT}

 # rewind
 git reset --hard HEAD~5

 # add another 10 commits
 for i in {1..10}; do
     date > foo.txt
     git add foo.txt
     git commit -m "bump" foo.txt
     sleep 1
 done;

这个脚本将添加10个虚拟提交，回退到5个提交之前并再次添加10个提交。在重置之前，它会打印出当前HEAD的哈希值。

我期望运行git gc --prune=all后丢失CURRENT中的对象。但是，我仍然可以对该哈希运行git show命令。

我知道，在运行git reset和添加新提交后，我实际上创建了一个新分支。但是我的原始分支已经没有任何引用了，因此它不会显示在git log --all中。它也不会被推送到任何远程分支。

我理解git gc的作用是删除这些对象。但事实并非如此。

为什么？那么，git gc什么时候会删除对象呢？

- exhuma

2

你的 reflog 仍然包含对你“删除”的提交的引用。除非它们超时或你明确地将它们过期，否则它们不会被修剪。 - twalberg

有趣。我看了一下 https://git-scm.com/docs/git-reflog 并运行了 git reflog --expire=all 命令。然后这个对象仍然存在。接下来我又运行了另一个 gc 命令，但它仍然存在。即使运行了另一个 git gc --aggressive --prune=all 命令也没有帮助。 - exhuma

您需要使用 --expire=all --all，或在 HEAD（默认）和 master 上运行它。或者您可以手动删除特定条目（或参见下面的答案）。 - torek

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- torek · Accepted Answer

为了使对象被修剪，它必须符合两个条件。一个是日期/时间相关的：它必须已经创建¹足够久以便被收集。 "足够久"部分是您使用--prune=all设置的：您正在覆盖正常的“至少两周前”的设置。

第二个标准是您的实验出了问题。为了被修剪，该对象还必须是不可访问的。正如twalberg在评论中指出的那样，每个被遗弃的提交（以及其对应的树和块）都通过Git的"reflog"条目引用。

每个这样的提交有两个reflog条目：一个是HEAD，另一个是HEAD在提交时所引用的分支名称的条目（在本例中，即refs/heads/master的reflog，即分支master）。每个reflog条目都有自己的时间戳，而git gc也会过期处理reflog条目，尽管其规则比默认的简单的“14天”对象到期规则更为复杂。²

因此，git gc 可以首先删除保留旧对象的所有reflog条目，然后对对象进行修剪。只是这里没有发生。

要手动查看或删除reflog条目，请使用git reflog命令。请注意，git reflog通过使用-g / --walk-reflogs选项（加上一些附加的显示格式选项）运行git log来显示这些条目。您可以运行git reflog --all --expire=all清除所有内容，但在需要更精细操作时，这可能是一个过度的方法。使用--expire-unreachable可以实现更多的选择性。有关更多信息，请参见git log文档和git reflog文档。

¹一些Unix文件系统根本不会存储文件的创建（“生日”）时间：一个stat结构的st_ctime字段是inode更改时间，而不是创建时间。如果存在创建时间，则在st_birthtime或st_birthtimespec中。然而，每个Git对象都是只读的，因此文件的创建时间也是其修改时间。因此，st_mtime始终可用，可为该对象提供创建时间。

²确切的规则在git gc文档中有详细说明，但我认为对于不可达提交，默认为30天；对于可达提交，默认为90天是一个不错的总结。然而，这里“可达”的定义比较特殊：它意味着从此reflog持有旧值的参考当前值开始可达。也就是说，如果我们查看master的reflog，我们会找到master标识的提交（例如1234567），然后查看每个master的reflog条目（例如master@{27}）是否从该特定提交（再次是1234567）可达。

³这个名字混淆问题是由POSIX标准化组织带来的 :-)。 st_birthtimespec字段是一个struct timespec，记录了秒和纳秒。