GIT Rebase在多个0.5GB二进制文件上出现致命错误

Question

[这个问题实际上是在重新打开一个从未得到答案的问题 git crash during rebase]

我正试图从我的“secc”分支进行变基：

$ git rebase main
First, rewinding head to replay your work on top of it...
fatal: Out of memory, malloc failed (tried to allocate 553656577 bytes)         # about 0.5 GB
$ git rebase --abort
No rebase in progress?

出错是因为两个分支及它们的共同祖先都有三个0.5GB的.dat文件。

在这种情况下，我该如何进行rebase操作？

额外信息:

• 'git merge main'命令完全可行。
• 通过在.gitattributes中添加'*.dat merge=keepTheirs'未能防止致命错误。
• *.dat文件不同。
• 我愿意删除*.dat文件以rebase其余文件，然后再添加回*.dat文件。但是，具体方法如何？
• 我使用的是 git 1.7.9.4 版本。

- GoZoner

---

据我所知（我从未需要将二进制文件添加到存储库中），git rebase会计算一个分支中的更改差异，并在另一个提交（另一个分支的“head”）上重新应用它们。看起来Git在比较如此大的二进制文件时会出现问题。如果我是你，我会将二进制文件移动到一个git子模块中，并保持简单的历史记录而不进行rebase操作。请参阅https://dev59.com/GHRB5IYBdhLWcg3wtZQV。 - KurzedMetal

你应该看一下git annex。Git annex是用于处理大文件的git扩展。它只在git存储库中存储控制数据，并将大文件本身保留在外部。 - bjhend

我刚刚查看了自1.7.10版本以来git的一些更新，有一些更改可以减少非常大文件的内存使用。因此，也许你可以尝试使用最新版本。 - torek

实际上，我通过使用更大的机器（32GB）解决了这个问题。- 所以实际问题是计算机内存不足，对吗？ - eis

.gitattributes 被跟踪吗？如果是，那么在 rebase 查看它时，它会看到未更正的版本。 - jthill

Answer 1

只有在'git rebase'失败时，您才会知道您的机器是否足够大，但此时您的目录已处于混乱状态。在rebase期间，另一个分支（main）被检出，以便将'secc'更改应用于它。恢复并继续进行：

git checkout secc

在rebase失败后，正如你所指出的，你有两个选择：

1. 如果不需要rebase，请使用“git merge main”
2. 获取更大的机器并重试“git rebase main”

你没有实际的选择来忽略0.5GB的文件，然后做rebase，并把那些巨型文件拿回来。

- GoZoner

Answer 2

在评论中，您说使用具有更多内存（在这种情况下为32GB）的计算机解决了该问题。基于此，我可以得出结论，您最初尝试的计算机可用内存太少，无法完成此操作。

- eis

---

当程序崩溃并将您的工作目录留在垃圾状态（但可恢复）后，您可能会说“哦，我需要一台更大的机器” - 这不是解决方案。 - GoZoner

问题似乎是a）可用内存太少和b）Git 处理不当。 a）我们可以采取一些措施，b）可能应该向 Git 开发人员报告。 - eis

除非当然最新版本的Git已经修复了这个问题。但是，即使它可以优雅地失败，你仍然没有足够的内存来完成这个任务。 - eis

内存太少，无法做什么 - 重新定位不就是将一个修订版本嫁接到另一个修订版本上吗？我猜它需要计算一个新的哈希值，但仅此而已 - git 不会将整个工作区加载到内存中以计算哈希值，对吧？Git 实际上需要多少内存作为工作区大小的倍数 - 是他的内存太少还是 Git 需要过多的内存来执行简单的操作？ - Rup

用户角度看有什么区别？就是需要比计算机可用内存更多的内存。 - eis

Answer 3

尝试将这些放在.git/info/attributes中：

# whatever gets them...
yourfile binary -delta merge=binary
*.yourext binary -delta merge=binary

如果这些文件发生更改，那么这将导致合并冲突，并且您必须想办法处理它们。请检查gitattributes和rebase文档以获取其他合并策略，我甚至不会在此处提及危险的策略。

我不确定是否尝试从运行中获取整个核心的实际合并，但这似乎值得一试。

- jthill