我应该在存储库克隆上还是在自托管裸存储库上使用 git-filter-repo ？

Question

Windows Server 上有一个自托管的 git 存储库（如果有人感兴趣，可以基于 Bonobo）。由于二进制 blob，存储库变得臃肿，我想删除这些大 blob 及其整个历史记录。

我被看着

bfg

/

git filter-branch

、

bfg-ish

和

git filter-repo

。我认为我的问题是不变的，但听起来

git filter-repo

是最建议的。

最大的问题：我应该在存储库克隆（工作副本）上执行

--strip-blobs-bigger-than 4M

，还是应该直接操作 Bobono 管理的托管裸存储库？如果我在客户端克隆上执行它，那么更改将如何传播到 Bonobo 中？这些变化将是非常根本性的，它们甚至可以提交吗？

我已经备份了所有内容，做了一些过滤器回购分析。我将这些 blob 包含在 gitignore 中（尽管它们的修改仍然显示为更改）。

Answer 1

我最终在托管的裸存储库上进行操作。看起来 filter-repo 旨在用于存储库的干净克隆：

git filter-repo --strip-blobs-bigger-than 4M
Aborting: Refusing to destructively overwrite repo history since
this does not look like a fresh clone.
  (expected freshly packed repo)
Please operate on a fresh clone instead.  If you want to proceed
anyway, use --force.

所以我重试了一个干净的克隆并运行了指令，但随后我不知道下一步该做什么。本身没有要提交或推送的文件更改，“元数据”已被修改。有趣的是，该操作还从

[remote "origin"]

中剥离了

[branch "master"]

和

.git/config

，因此我需要重新建立远程和分支。

所以我决定继续修改托管的裸存储库。该工具识别出它不是干净的克隆：

warning: no corresponding .pack: ./objects/pack/pack-f8fc2556f0b95c1a66219fe3ad3fe41d6319a985.idx
Aborting: Refusing to destructively overwrite repo history since
this does not look like a fresh clone.
  (expected freshly packed repo)
Please operate on a fresh clone instead.  If you want to proceed
anyway, use --force.

强制元数据大小从 1.3GB 减少到 150MB，与在干净克隆元数据上执行类似。

> git filter-repo --force --strip-blobs-bigger-than 4M
Processed 19965 blob sizes
Parsed 3536 commits
New history written in 1.44 seconds; now repacking/cleaning...
Repacking your repo and cleaning out old unneeded objects
Enumerating objects: 42458, done.
Counting objects: 100% (42458/42458), done.
Delta compression using up to 8 threads
Compressing objects: 100% (12993/12993), done.
Writing objects: 100% (42458/42458), done.
Selecting bitmap commits: 3257, done.
Building bitmaps: 100% (137/137), done.
Total 42458 (delta 33284), reused 37896 (delta 29067), pack-reused 0
Removing duplicate objects: 100% (256/256), done.
Completely finished after 10.20 seconds.

这恰好是一个 Windows 环境，之后我开始了一个干净的克隆，我必须重新信任 Visual Studio 中的存储库等等。到目前为止，我可以推动一些更改，如果有任何问题似乎不起作用，我会报告。

如果您正在处理由 GitHub 或其他 git 服务管理的存储库，那就是另一回事了，在这种情况下，您将无法直接访问它们管理的裸存储库。不确定在这种情况下会发生什么。我想你可以以某种方式推动元数据更改？应该有人评论。