Git 使用 BFG 后存储库只会变大
Git Repository Only Gets Bigger After Using BFG
我们目前正在将我们的 SVN 存储库迁移到 GIT（托管在 bitbucket）。
我使用 subgit 将我们所有的 branches/history 导入到我的 (Windows) PC 本地的一个裸仓库中。
回购相当大（导入后 7.42 GB）这是因为它还包含有关 SVN 的信息，例如修订号，以提供一种在 Git 和 SVN 之间进行双向同步的方法（我'我只对 SVN 到 GIT) 的一种方式感兴趣。
我创建了导入的裸仓库的本地克隆并将所有分支推送到 bitbucket。
几个小时后（！），回购已完全上传。 BitBucket 现在向我发出有关回购大小的警告。我检查了大小，它是 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 之后（作为一个新的 repo，而不是作为一个强制推送）它只变得更大 (1.8GB)
您能否对此行为提供可能的解释？
我不知道这是否重要，但我们在 svn 中使用了非标准 branch/tag 模型。这导致分支如下：
/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 删除？
对不起，我有很多问题！
有人可以帮我解决这个问题吗？
谢谢，
皮特
我在对你的问题的评论中要求提供更多诊断信息，这些信息是对主要部分给出合理答案所必需的，但对于你的次要问题（Whosebug 鼓励你单独提问，顺便说一句!)，这里有一些提示：
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 散列）分配 ID，就此而言，不关心您的文件是否为文本 - 如果文件略有不同，它们的 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 可以相当快地完成一项任务（即使使用起来很麻烦）。
包大小增加问题（在 运行 BFG 之后）对我重新浮出水面，最终归因于 git 版本 2.18 时代版本包问题。使用 2.19 的同事没有问题，我能够在 2.19 中找到错误修复说明。
我们目前正在将我们的 SVN 存储库迁移到 GIT（托管在 bitbucket）。 我使用 subgit 将我们所有的 branches/history 导入到我的 (Windows) PC 本地的一个裸仓库中。
回购相当大（导入后 7.42 GB）这是因为它还包含有关 SVN 的信息，例如修订号，以提供一种在 Git 和 SVN 之间进行双向同步的方法（我'我只对 SVN 到 GIT) 的一种方式感兴趣。
我创建了导入的裸仓库的本地克隆并将所有分支推送到 bitbucket。 几个小时后（！），回购已完全上传。 BitBucket 现在向我发出有关回购大小的警告。我检查了大小，它是 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 之后（作为一个新的 repo，而不是作为一个强制推送）它只变得更大 (1.8GB)
您能否对此行为提供可能的解释？
我不知道这是否重要，但我们在 svn 中使用了非标准 branch/tag 模型。这导致分支如下：
/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 删除？
对不起，我有很多问题！ 有人可以帮我解决这个问题吗？
谢谢，
皮特
我在对你的问题的评论中要求提供更多诊断信息，这些信息是对主要部分给出合理答案所必需的，但对于你的次要问题（Whosebug 鼓励你单独提问，顺便说一句!)，这里有一些提示：
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 散列）分配 ID，就此而言，不关心您的文件是否为文本 - 如果文件略有不同，它们的 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 可以相当快地完成一项任务（即使使用起来很麻烦）。
包大小增加问题（在 运行 BFG 之后）对我重新浮出水面，最终归因于 git 版本 2.18 时代版本包问题。使用 2.19 的同事没有问题，我能够在 2.19 中找到错误修复说明。