Git pull fatale: de mémoire, malloc a échoué

J'ai un repo sur https://bitbucket.org/

Il ya quelques jours par une erreur grand nombre de fichiers d'image ont été poussés dans le repo. ensuite, les fichiers ont été supprimés par l'intermédiaire d'une poussée. après que les pensions de travaillé ok, mais aujourd'hui quand j'essaie de retirer de l'opération:

$ git pull
Password for 'https://[email protected]': 
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

J'ai essayé:
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

Pas de chance là-bas, vous ne savez pas quelles mesures dois-je prendre la prochaine...
La taille de l'opération devrait être autour de 10-20m de code. quelles mesures dois-je prendre?

Mise à JOUR de 1
j'ai exécuté les commandes suivantes:

$ 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://[email protected]/repo.git
 + 203e824...ed003ce demo -> demo (forced update)
 + d59fd1b...a1c9fb8 master -> master (forced update)

Tirer ensuite des œuvres ok:

$ git pull
Already up-to-date.

Mais quand j'essaie de cloner le repo-je obtenir

~/www/clone$ git clone [email protected]: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

Mise à JOUR 2
Malheureusement je n'ai pas trouvé tous les fichiers de grande taille. certains sont encore en à gauche. J'ai donc demandé le soutien de tuer tous les journaux de l'opération

Mise à JOUR 3
À la fin, j'ai dû tuer la vieille & créer de nouvelles pensions.

Darn. Ils (BitBucket) n'a pas été nettoyé correctement votre pension, alors. Votre solution est bonne (plus pratique que la mienne ci-dessous), même si vous devez changer votre adresse repo distant.
Je suis fatigué de rechercher une mauvaise dent 😉

OriginalL'auteur Elmor | 2012-12-26

4

Si vous êtes le seul à utiliser ce repo, vous pouvez suivre l'git filter-branch option décrite dans "Comment purger un énorme fichier de commet l'histoire dans Git?"

L'option plus simple est de cloner le repo à un ancien commit, et à force de pousser, comme décrit dans "git-filter-branch pour supprimer les fichiers volumineux".

Soit un aurait la force de tout collaborateur de réinitialiser son propre repo local pour le nouvel état que vous publiez. Encore une fois, si vous êtes le seul collaborateur, il n'est pas un problème.

les collaborateurs ne sont pas le problème. maintenant, j'ai le clonage d'erreur. voir la mise à jour 1
ensuite, vous devez communiquer avec BitBucket pour exécuter un git gc " sur votre repo (comme indiqué dans le stackoverflow.com/a/11404097/6309). Ils ne doivent fonctionner de toute façon (confluence.atlassian.com/pages/viewpage.action?pageId=287998264), mais je ne suis pas sûr si le git push --force n'déclencher dit git gc.
De Plus, BitBucket peut pas nettoyer récente supprimé de l'histoire, de sorte que vous pourriez encore avoir à contacter BitBucket pour faire un peu plus d'un nettoyage en profondeur: git gc --prune=today --aggressive ou même plus, comme décrit dans la stackoverflow.com/a/1908476/6309
Merci, a écrit à l'appui de bitbucket. en attente de la réaction 😉

OriginalL'auteur VonC
7

Dans mon cas, c'était quelque chose d'aussi simple que d'essayer de tirer un grand repo dans un 1GO de RAM sans swap.

J'ai suivi ce tutoriel https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04 pour créer l'espace de swap sur le serveur et travaillé.

Leur "plus vite" façon:
```
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
```
Vous pouvez faire ces modifications permanentes en ajoutant dans /etc/fstab:
```
/swapfile   none    swap    sw    0   0
```
Ils vous recommandons d'ajouter à /etc/sysctl.conf:
```
vm.swappiness=10
vm.vfs_cache_pressure = 50
```
J'ai utilisé leur "plus rapide", mais avec 1G et il a résolu mon problème, merci!
C'était ce dont j'avais besoin et pas seulement à pack & pousser, mais à cloner.
Wow! Merci mec, vous avez sauvé la journée
Cela a fonctionné génial sur mon raspberry pi serveur git!!!!

OriginalL'auteur steinkel
2

Même si les gros fichiers d'image ont été supprimés après avoir été poussé, ils restent dans la git histoire.

Je suggère à force de les supprimer de l'historique de git (je pense que c'est possible, mais cela implique une procédure délicate que je ne sais pas).

Sinon, tirez le dépôt avant le, à tort, l'ajout de fichiers, le correctif le référentiel pour les petites taches, clone, et de l'utiliser (peut-être avec un dump/restore) de votre master git.

^{je ne sais pas bien les détails, mais j'ai lu qu'il pourrait être possible}

Merci pour les instructions générales 😉

OriginalL'auteur Basile Starynkevitch
0

J'ai récemment rencontré ce problème avec un de mes dépôts. Erreur similaire, faisant allusion à un gros fichier caché dans la mise en pension quelque part.
```
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
```
Pour contourner ce problème j'ai temporairement créé un grand swap de disque (dans l'excès de la 893191377 octets le serveur demande) à la suite de Méthode 2 à partir d'ici: http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/

Cela m'a permis de cloner avec succès, puis de supprimer le coupable (quelqu'un a vérifié dans un sql dumpfile). Vous pouvez utiliser:
```
git filter-branch --tree-filter 'rm -rf dumpfile.sql' HEAD
```
pour supprimer le fichier à partir du repo git.

OriginalL'auteur mbarnettjones

Vous devez vous connecter pour publier un commentaire.