Git pull fatal: из памяти, malloc не удалось

у меня РЕПО на https://bitbucket.org/

несколько дней назад по ошибке большое количество файлов изображений было помещено в репо. затем файлы были удалены с помощью другого нажатия. после этого РЕПО работало нормально, но сегодня, когда я пытаюсь вытащить из РЕПО:

$ 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)

Pull затем работает нормально:

$ 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
В конце концов мне пришлось убить старый и создать новый РЕПО.

9
bitbucket clone git git-clone memory

4 ответов

Если вы единственный, кто использует это РЕПО, вы можете следовать опции git filter-branch, описанной в "Как очистить огромный файл от истории коммитов в Git?"

более простой вариант-клонирование РЕПО на старый фиксатор и принудительное его нажатие, как описано в "git-filter-branch удалить большой файл".

любой из них заставит любого сотрудника сбросить собственное локальное РЕПО в новое состояние, которое вы публикуете. Опять же, если вы единственный коллаборационист, это не проблема.

4

в моем случае это было что-то простое, как попытка вытащить большое РЕПО в 1GB RAM box без свопа.

Я следил за этим учебником 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

они рекомендуют добавить к /и т. д./sysctl.conf:

vm.swappiness=10
vm.vfs_cache_pressure = 50
7

даже если большие файлы изображений были удалены после нажатия, они остаются в git история.

Я бы предложил принудительно удалить их из истории git (я думаю, что это возможно, но это включает в себя деликатную процедуру, которую я не знаю).

альтернативно, вытащите репозиторий перед ошибочно добавленными файлами, исправьте репозиторий, чтобы сделать соответствующие небольшие исправления, клонировать это и использовать это (возможно, с дампом / восстановлением) в качестве вашего мастера мерзавец.

Я не знаю хорошо деталей, но я прочитал, что это может быть возможно

2

недавно я столкнулся с этой проблемой с одним из моих хранилищ. Аналогичная ошибка, намекающая на большой файл, скрытый где-то в репо. 

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.

0