【问题标题】：How can I resume a git history rewrite?如何恢复 git 历史重写？
【发布时间】：2013-04-15 16:01:24
【问题描述】：

我正在使用git filter-branch --tree-filter 重写一个相当大的回购的历史，这需要几个小时。我看到 git 正在使用一个临时目录来存储它的中间工作。这是否意味着如果它被中断可以恢复重写？如果有，怎么做？

编辑

我正在做的操作是移动几个目录。这些当前位于子目录中，但我现在需要它们位于根目录中。

例如

dir1
- dir2
- dir3
- dir4

变成

dir1
- dir2
dir3
dir4

当然，我的目录结构比这复杂得多，但这就是我想要做的事情的要点。

【问题讨论】：

出于好奇（不是您问题的核心），您能描述一下您使用--tree-filter 执行的操作吗？删除或修改文件？

标签： git git-filter-branch git-rewrite-history

【解决方案1】：

git filter-branch 本身不支持挂起/恢复使用模式 - 尽管它会将临时数据写入.git-rewrite 文件夹，但实际上不支持基于此目录的内容恢复。如果您在以前中止了 filter-branch 操作的存储库上运行 git filter-branch，它会要求您删除该临时文件夹，或者使用 --force 选项，do it itself。

根本问题是git-filter-branch 在大型存储库上运行缓慢 - 如果该过程快得多，则没有尝试恢复的动力。所以你有几个选择：

让 git-filter-branch 运行得更快一些...

使用RAM-disk - git-filter-branch 会占用大量 IO，并且在您的存储库位于 RAM 中时运行速度会更快。
使用--index-filter 而不是--tree-filter - 它类似于树过滤器，但不检查文件树，这使其更快，但确实需要您重写文件更改就 git index 命令而言。
使用cloud computing 并租用具有快速内存和高时钟速度的机器（不要打扰多核，除非您自己的命令是多线程的，因为git-filter-branch 本身是单线程的）

...或使用 BFG （更快）

BFG Repo-Cleaner 是 git-filter-branch 的更简单、更快的替代方案 - 在大型存储库中，它比 50-150x 更快。这会将您需要几个小时的工作变成只需要几分钟的工作。

全面披露：我是 BFG Repo-Cleaner 的作者。

【讨论】：

感谢您的指点。在带有 RAM 磁盘的 Linux VM 中运行显着加快了速度。我无法使用 BFG Repo-Cleaner，因为我正在做的操作是移动几个目录，以便它们位于根目录而不是子目录中。据我所知，这使得--index-filter 也很棘手，因为git mv 不能单独用于索引。
很高兴加快了速度。顺便说一句，移动/删除目录是我正在考虑添加到 BFG 的一项功能——完成后我会添加评论。感谢您提供使用示例！
@alnorth29 抱歉，还有一个问题 - 移动子目录的理由是什么？为什么有必要？
部分是这样，但我们也有 8 个需要在移动中合并的分支。在每个分支上分别进行重新排列，然后尝试从一个分支合并到另一个分支将是一场噩梦。
再次感谢 BFG，在这里。运行 git-filter-branch （使用 naive --tree-filter）花了将近 3 周的时间才能完成我们过大的 repo 的 97%，然后它运行的 linux VM 遭受文件系统损坏并且失败（！） .用 BFG 完成相同的操作不到 20 分钟，并且在所有分支机构都有效！

【解决方案2】：

Roberto 在他的回答中提到了这一点，但我想给它一个基准：如果您的 git filter-branch 操作需要很长时间才能完成，请考虑使用 AWS 高内存实例。

我曾经不得不 filter-branch 将 35 个不同的存储库合并在一起，每个存储库都有两年每天数十次提交的历史。我的脚本在我的笔记本电脑上未能在 25 小时内完成。它在 Amazon 的 m2.4xlarge 实例上在 45 分钟内完成。

总费用？

1.64 美元——比我在 20 盎司苏打水上的花费还少。

BFG 听起来是一个很棒的工具，我鼓励任何经常改写历史的人尝试一下。但是，如果您只是需要一些东西来工作并且可以轻松访问 AWS，filter-branch 非常简单。

在 2016 年，这甚至更便宜。 只需继续访问 Spot Advisor，并为自己找到一些“每小时 0.30 美元的集群计算”。

【讨论】：