使用 BFG 后，Git 存储库只会变得更大

Question

我们目前正在将我们的 SVN 存储库迁移到 GIT(托管在 bitbucket 上)。
我使用 subgit 将我们所有的分支/历史导入到我在(Windows)PC 本地拥有的裸仓库中。

存储库非常大(导入后为 7.42 GB)这是因为它还包含有关 SVN 的信息，例如修订号，以提供一种在 Git 和 SVN 之间进行双向同步的方法(我只对 SVN 的单向同步感兴趣) GIT)。

我创建了导入的裸仓库的本地克隆并将所有分支推送到 bitbucket。
几个小时后(!)，repo 已完全上传。 BitBucket 现在给了我关于 repo 大小的警告。我检查了大小，它是 1.1GB。这不像导入的裸机那么大，但仍然有一个快速的存储库。

在玩过 BFG 之后，我设法在裸仓库上使用这些命令删除了 soms 大型 DLL/SQL 导出文件(我只使用克隆进行推送，而没有所有与 svn 相关的引用):

java -jar bfg.jar --delete-files '{''specialized 2015''','''specialized,''insert-pcreeks''}.sql' --no-blob-protection

java -jar bfg.jar --delete-files 'Incara.*.dll' --no-blob-protection Incara.git

git reflog expire --expire=now --all && git gc --prune=now --aggressive

这花了一段时间，之后 git_find_big.sh 脚本不再显示这些大型 sql 文件。但是在将东西推回 bitbucket(作为新的存储库，而不是强制推送)之后，它只会变得更大(1.8GB)

你能为这种行为提供一个可能的解释吗？

我不知道这是否重要，但我们在 svn 中使用了非标准的分支/标签模型。这导致分支如下: /refs/heads/archive/some/path/to/branch .这些分支似乎工作得很好，删除它们也不会影响大小。

在这些问题旁边，我注意到我在 git_find_big.sh 中显示了一些 XML 文件。输出:

size,pack,SHA,location 12180,1011,56731c772febd7db11de5a66674fe6a1a9ec00a7 repository/frontend.xml 12074,1002,0cefaee608c06621adfa4a9120ed7ef651076c33 repository/frontend.xml 12073,1002,a1c36cf49ec736a7fc069dcc834b784ada4b6a06 repository/frontend.xml 12073,1002,1ba5bd92817347739d3fba375fc42641016a5c1d repository/frontend.xml 12073,1002,e9182762bfc5849bc6645fdd6358265c3930779f repository/frontend.xml 12073,1002,dff5733d67cb0306534ac41a4c55b3bbaa436a2e repository/frontend.xml 12072,1002,8ee628f645ce53d970c3cf9fdae8d2697224e64c repository/frontend.xml 12072,1002,1266dee72b33f7a05ca67488c485ea8afc323615 repository/frontend.xml

这些文件包含我们正在使用的 Web 平台的前端逻辑，并且确实相当大。
但它们应该被视为文本，对吗？因此我不明白为什么它们在上面的输出中显示为单独的对象。我是对的，这不应该发生吗？

SVN 导入也导致了一些空提交(例如，当 SVN 创建或移动一个分支时，它需要一个新的提交)。我猜这些只能使用 filter-branch 删除？

对不起，我有很多问题!
有人可以帮我解决这个问题吗？

谢谢，

皮特

Answer 1

我在对您的问题的评论中要求提供更多诊断信息，这是对主要部分给出合理答案所必需的，但至于您的次要问题(顺便说一句，Stackoverflow 鼓励您单独提问!)，这里是一些提示:

Next to these problems i noticed i had some XML files showing up in the git_find_big.sh output: [snip]

These files contain the frontend logic of the web platform we are using and are indeed quite big. But they should be treated as text right? Therefore I don't get why they show up as separate objects in the above output. Am i right this should not be happening?

Git 根据文件的内容(一个 SHA 哈希)分配 ids，就这一点而言，并不关心你的文件是否是文本——如果文件甚至略有不同，它们的 id 就会不同，并且将是单独存储(Git 可能会在后台进行增量压缩，但这并不能阻止文件被定义为逻辑上独立的)。因此，同一文件的不同版本在 git_find_big.sh 中出现不止一次也就不足为奇了。输出。

The SVN import also resulted in some empty commits (for example when SVN creates or moves a branch it needs a new commit). I guess these can only be removed using filter-branch?

是的，BFG 不会开箱即用。然而，这是一项任务 filter-branch确实做得相当快(即使它使用起来很繁琐)。