大包文件git无法解决 [英] Large pack file git not solved

问题描述

我的问题与这一问题相同.删除由git创建的大型.pack文件

My question is identical to this one. Remove large .pack file created by git

我遵循了此处列出的所有步骤: https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery ，还尝试了

I followed all the steps listed here: https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery and also tried all the steps listed in this accepted answer. However, the size of the pack file is still large.

之前:

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 |排序-k 3 -n |tail -3 并看到三个最大的文件及其对应的提交，但是当我运行 git log --oneline --branches-< large_file_name> 时，没有引用该文件的提交文件，这可能是因为我重写了提交的历史记录.显然，我似乎已经搞砸了.

I can still run this command: git verify-pack -v .git/objects/pack/pack-xxx.idx | sort -k 3 -n | tail -3 and see the three largest files and their corresponding commits but when I run git log --oneline --branches -- <large_file_name>, there are no commits which reference the file, which may be because I rewrote the history of commits. Clearly, I seem to have messed up somewhere along the line.

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

My question is, how to fix this issue regarding the large .pack file?

推荐答案

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

... when I run git log --oneline --branches -- <large_file_name>, there are no commits which reference the file, which may be because I rewrote the history of commits ...

没关系(假设这是您的意图).您现在需要做的是确保没有 other 个外部引用到达使用该文件的提交.

That's fine (assuming that's your intent). What you need to do now is make sure no other external references reach commits that use the file(s).

使用-分支告诉 git log 或 git rev-list ¹ 查看所有分支名称引用，即 refs/heads/下的所有内容.但是在 refs/tags/下可能有标签名称引用，因此您应该在此处进行检查.甚至可能还有其他参考，因此您应该检查所有这些参考.最简单的方法是使用-all 而不是-branches :查看所有引用.

Using --branches tells git log or git rev-list¹ to look at all branch name references, i.e., everything under refs/heads/. But there may be tag name references under refs/tags/, so you should check there. There may even be other references, so you should check all of them. The easiest way to do that is to use --all rather than --branches: that looks at all references.

但是，这也会错过 reflogs..每个引用都有(至少潜在地)一个reflog.要遍历reflog，请使用 -g 或-walk-reflogs .请注意，您必须单独执行此操作.如果有一个引用提交的reflog条目，则可以手动使它过期；否则，请执行以下操作.或者您可以使用蛮力方法使所有reflog批发都过期(这有点危险，因为reflog是您的主要安全网，但您 都是在 copy 的原始存储库，对吧?:-)).

But this also misses the reflogs. Every reference has (at least potentially) a reflog. To walk the reflogs, use -g or --walk-reflogs. Note that you must do this separately. If there's a reflog entry that references the commit, you can expire it manually; or you can use the brute-force method of just expiring all reflogs wholesale (which is a little dangerous since the reflogs are your main safety net, but you are doing all this on a copy of the original repository, right? :-) ).

请注意，当您使用 git filter-branch 重写历史记录"时，实际上是在将所有历史记录复制到新的历史记录中.这样，您可以临时将存储库大小增加到大约两倍，具体取决于您在过滤器中执行的操作.删除旧的reflog并删除 refs/original/命名空间下保存的原始引用，然后进行垃圾回收，应将内容缩小到一定大小.

Note that when you use git filter-branch to "rewrite history", you're really copying all of history to a new history. As such, you can temporarily increase the repository size up to about double, depending on what you do in your filters. Removing old reflogs and removing the saved original references under the refs/original/ namespace, followed by garbage collection, should shrink things back to size.

还请注意，如果一个打包文件具有相应的 .keep 文件，即使在构建了一个涵盖所有内容的新打包后，Git也不会丢弃保留的打包.任何 .keep 文件都是手动创建的，并且在适当的时候必须手动删除.

Note also that if a pack file has a corresponding .keep file, Git won't throw out the kept pack even after building a new pack that covers everything. Any .keep files were created manually and must be removed manually if and when that's appropriate.

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

¹These two commands, git log and git rev-list, are actually pretty much just one command, built from one source file, builtin/log.c. They have slightly different entry points, that set up some different default options, and git log will start from HEAD if you don't name any other starting points, while git rev-list demands some starting points.

这篇关于大包文件git无法解决的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！