几天前由于一个错误,大量的图像文件被推入了回购。然后通过另一个推送删除文件。在那个回购工作正常之后,但今天当我试图从回购中撤出时:
$ 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
那里没有运气,不确定我接下来应采取什么行动...... 回购的大小应该是大约10-20米的代码。我接下来应该采取什么行动?
更新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.
但是当我尝试克隆回购时,我得到了
~/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
可悲的是,我没有找到所有的大文件。有些人还在离开。所以我要求支持杀死回购的所有日志
更新3
最后我不得不杀死旧的&创建新的回购。
答案 0 :(得分:8)
在我的情况下,它就像在没有交换的情况下在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
答案 1 :(得分:4)
如果您是唯一使用此回购的人,可以按照“How to purge a huge file from commits history in Git?”中描述的git filter-branch选项进行操作
更简单的选项是将repo克隆到旧提交,并强制推送它,如“git-filter-branch
to delete large file”中所述。
任何一方都会强迫任何协作者将他/她自己的本地仓库重置为您要发布的新州。同样,如果您是唯一的合作者,那不是问题。
答案 2 :(得分:2)
即使大图像文件在被推送后被删除,它们也会保留在git
历史记录中。
我建议强行将它们从git历史中删除(我认为这是可能的,但它涉及一个我不知道的精巧程序)。
或者,在错误添加的文件之前拉出存储库,修补存储库以生成相关的小补丁,克隆它,并使用它(可能使用转储/恢复)作为主git。
我不太清楚细节,但我确实读过它可能
答案 3 :(得分:0)
我最近遇到了一个我的存储库的问题。类似的错误,暗示隐藏在repo某处的大文件。
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
为了解决这个问题,我暂时在此处方法2 之后创建了一个大型交换驱动器(超过服务器要求的893191377字节):http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/
这允许我成功克隆然后删除罪魁祸首(某人已经签入了sql dumpfile)。您可以使用:
git filter-branch --tree-filter 'rm -rf dumpfile.sql' HEAD
从git repo中删除文件。