Question

我的问题与此问题相同。 Remove large .pack file created by git

我按照此处列出的所有步骤操作：https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery并尝试了此accepted answer中列出的所有步骤。但是，包文件的大小仍然很大。

在：

count: 0
size: 0
in-pack: 2259
packs: 1
size-pack: 67333
prune-packable: 0
garbage: 0
size-garbage: 0

后：

count: 0
size: 0
in-pack: 2259
packs: 1
size-pack: 67333
prune-packable: 0
garbage: 0
size-garbage: 0

我仍然可以运行这个命令：git verify-pack -v .git/objects/pack/pack-xxx.idx | sort -k 3 -n | tail -3并查看三个最大的文件及其相应的提交但是当我运行git log --oneline --branches -- <large_file_name>时，没有提交引用该文件的提交，这可能是因为我重写了承诺的历史。很明显，我似乎已经搞砸了。

我的问题是，如何解决有关大型.pack文件的问题？

Answer 1

...当我运行git log --oneline --branches -- <large_file_name>时，没有提交引用该文件的提交，这可能是因为我重写了提交的历史......

那很好（假设这是你的意图）。您现在需要做的是确保没有其他外部引用到达使用该文件的提交。

使用--branches告诉git log或git rev-list ¹查看所有分支名称引用，即{{1}下的所有内容1}}。但refs/heads/下可能有标记名称引用，因此您应该在那里查看。甚至可能有其他参考，所以你应该检查所有参考。最简单的方法是使用refs/tags/而不是--all：查看所有引用。

但这也错过了 reflogs。每个引用都有（至少可能）一个reflog。要浏览reflog，请使用--branches或-g。请注意，您必须单独执行此操作。如果存在引用提交的reflog条目，则可以手动使其过期;或者你可以使用刚刚过期批发所有reflogs的强力方法（这有点危险，因为reflogs是你的主要安全网，但你在副本上做这一切< / em>原始存储库，对吧？:-)）。

请注意，当您使用--walk-reflogs“重写历史记录”时，您实际上将所有历史记录复制到新历史记录中。因此，您可以暂时将存储库大小增加到大约两倍，具体取决于您在过滤器中执行的操作。删除旧的reflog并删除git filter-branch命名空间下保存的原始引用，然后进行垃圾回收，可以将内容缩小到适当的大小。

另请注意，如果包文件具有相应的refs/original/文件，即使在构建涵盖所有内容的新包之后，Git也不会丢弃保留的包。任何.keep文件都是手动创建的，必须在适当时手动删除。

¹这两个命令.keep和git log实际上只是一个命令，由一个源文件builtin/log.c构建。它们的入口点略有不同，设置了一些不同的默认选项，如果您没有命名任何其他起点，git rev-list将从git log开始，而HEAD需要一些起点

大包文件git没有解决

1 个答案: