Git拉致命：内存不足，malloc失败答案

【问题标题】：Git pull fatal: Out of memory, malloc failedGit拉致命：内存不足，malloc失败
【发布时间】：2023-03-10 07:03:02
【问题描述】：

几天前错误地将大量图像文件推送到存储库中。然后文件通过另一个推送被删除。在那之后回购工作正常，但是今天当我尝试从回购中提取时：

$ git pull
Password for 'https://repo@bitbucket.org': 
warning: no common commits
remote: Counting objects: 4635, done.
remote: Compressing objects: 100% (1710/1710), done.
fatal: Out of memory, malloc failed (tried to allocate 4266852665 bytes)
fatal: index-pack failed

我试过了：
1) git config --global pack.windowMemory 1024m
2)

$ git count-objects -v
count: 9
size: 48
in-pack: 4504
packs: 1
size-pack: 106822
prune-packable: 0
garbage: 0

没有运气，不知道接下来我应该采取什么行动......
repo 的大小应该在 10-20m 左右的代码。我接下来应该采取什么行动？

更新 1
我执行了这些命令：

$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch public/images/*' HEAD
Rewrite a1c9fb8324a2d261aa745fc176ce2846d7a2bfd7 (288/288)
WARNING: Ref 'refs/heads/master' is unchanged

和

$ git push --force --all
Counting objects: 4513, done.
Compressing objects: 100% (1614/1614), done.
Writing objects: 100% (4513/4513), 104.20 MiB | 451 KiB/s, done.
Total 4513 (delta 2678), reused 4500 (delta 2671)
remote: bb/acl: ayermolenko is allowed. accepted payload.
To https://repo@bitbucket.org/repo.git
 + 203e824...ed003ce demo -> demo (forced update)
 + d59fd1b...a1c9fb8 master -> master (forced update)

然后拉动就可以了：

$ git pull
Already up-to-date.

但是当我尝试克隆 repo 时，我得到了

~/www/clone$ git clone git@bitbucket.org:repo.git
Cloning into 'clone'...
remote: Counting objects: 5319, done.
remote: Compressing objects: 100% (1971/1971), done.
fatal: Out of memory, malloc failed (tried to allocate 4266852665 bytes)
fatal: index-pack failed

更新 2
可悲的是，我没有找到所有的大文件。有些还剩下。所以我请求支持来杀死所有的 repo 日志

更新 3
最后我不得不杀死旧的并创建新的回购。

【问题讨论】：

该死。然后，他们（BitBucket）没有正确清理您的回购。即使您必须更改远程仓库地址，您的解决方案也是一个不错的解决方案（比我下面的更实用）。
我厌倦了寻找坏牙;)

标签： git memory clone bitbucket git-clone

【解决方案1】：

在我的情况下，这就像尝试在没有交换的 1GB RAM 盒子中提取一个大仓库一样简单。

我按照本教程https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04 在服务器上创建了一些交换空间并工作了。

他们“更快”的方式：

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

您可以通过添加到 /etc/fstab 使这些更改永久化：

/swapfile   none    swap    sw    0   0

他们建议添加到 /etc/sysctl.conf：

vm.swappiness=10
vm.vfs_cache_pressure = 50

【讨论】：

我使用了他们的“更快的方式”，但使用 1G 解决了我的问题，谢谢！
我不仅需要打包和推送，还需要克隆。
哇！谢谢老兄，你拯救了这一天

【解决方案2】：

如果您是唯一使用此 repo 的人，您可以按照“How to purge a huge file from commits history in Git?”中描述的 git filter-branch 选项进行操作

更简单的选择是将 repo 克隆到旧提交，然后强制推送它，如“git-filter-branch to delete large file”中所述。

任何一方都会强制任何合作者将他/她自己的本地存储库重置为您正在发布的新状态。同样，如果您是唯一的合作者，这不是问题。

【讨论】：

合作者没有问题。现在我有克隆错误。见更新 1
@Elmor 然后您需要联系 BitBucket 以便他们在您的存储库上运行“git gc”（如stackoverflow.com/a/11404097/6309 中所述）。他们无论如何都应该运行它（confluence.atlassian.com/pages/viewpage.action?pageId=287998264），但我不确定git push --force 是否触发了git gc。
@Elmor Plus，BitBucket 可能无法清除最近删除的历史记录，因此您可能仍需要联系 BitBucket 以进行更彻底的清理：git gc --prune=today --aggressive 甚至更多，如stackoverflow.com/a/1908476/6309 中所述
感谢，写信给bitbucket的支持。等待反应;)

【解决方案3】：

即使大图像文件在被推送后被删除，它们也会保留在git历史记录中。

我建议将它们从 git 历史记录中强行删除（我认为这是可能的，但它涉及一个我不知道的微妙过程）。

或者，在错误添加的文件之前提取存储库，修补存储库以制作相关的小补丁，克隆它，并将其用作您的主 git（可能带有转储/恢复）。

^{我不是很清楚细节，但我确实读过它是可能的}

【讨论】：

感谢您的一般说明；）

【解决方案4】：

我最近在我的一个存储库中遇到了这个问题。类似的错误，暗示某个地方的仓库中隐藏了一个大文件。

Cloning into 'test_framework'...
remote: Counting objects: 11889, done.
remote: Compressing objects: 100% (5991/5991), done.
Receiving objects:  66% (7847/11889), 3.22 MiB | 43 KiB/sremote: fatal: Out of memory, malloc failed     (tried to allocate 893191377 bytes)
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOFs:  66% (7933/11889), 3.24 MiB
fatal: index-pack failed

为了解决这个问题，我临时创建了一个大型交换驱动器（超过服务器要求的 893191377 字节），遵循 方法 2 从这里开始：http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/

这使我能够成功克隆然后删除罪魁祸首（有人签入了 sql 转储文件）。你可以使用：

git filter-branch --tree-filter 'rm -rf dumpfile.sql' HEAD

从 git repo 中删除文件。

【讨论】：