Échec du remballage du repository Git

J’ai un repository git résidant sur un serveur avec une mémoire limitée. Lorsque j’essaie de cloner un référentiel existant à partir du serveur, j’obtiens l’erreur suivante

hemi@ubuntu:$ git clone ssh://hemi@servername.dk/home/hemi/repos/articles Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/ hemi@servername.dk's password: remote: Counting objects: 666, done. remote: warning: suboptimal pack - out of memory remote: fatal: Out of memory, malloc failed error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed hemi@ubuntu:$ 

Pour gérer cette erreur, j’ai essayé de remballer le repository d’origine (d’après ce message sur le forum ). Mais au lieu de remballer le référentiel, il décrit comment utiliser la commande “git pack-objects”.

 hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m usage: git pack-objects [{ -q | --progress | --all-progress }] [--all-progress-implied] [--max-pack-size=N] [--local] [--incremental] [--window=N] [--window-memory=N] [--depth=N] [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] [--stdout | base-name] [--include-tag] [--keep-unreachable | --unpack-unreachable [<ref-list | <object-list] 

Git 1.6.5.7 est installé sur le serveur.

Votre solution vous a fourni une copie de travail localement et à distance, mais vous rencontrerez des problèmes lorsque le référentiel distant décidera de se réemballer. Heureusement, vous pouvez définir des options de configuration qui réduiront la quantité de mémoire requirejse pour le remballage dans les deux référentiels. Ces parameters font en sorte que les parameters de la ligne de commande que vous avez ajoutés sont les options par défaut lors du reconditionnement. Donc, vous devez vous connecter à la télécommande, passer dans le référentiel et faire:

 git config pack.windowMemory 10m git config pack.packSizeLimit 20m 

Vous souhaiterez peut-être faire la même chose sur votre référentiel local. (Incidemment, je suppose que soit votre repository est très grand ou ce sont des machines avec peu de mémoire – ces valeurs me semblent très faibles.)

Pour ce qui est de la peine, lors de l’obtention d’échecs de malloc sur le repacking de référentiels très volumineux, j’ai également modifié les valeurs de core.packedgitwindowsize , core.packedgitlimit , core.deltacachesize , pack.deltacachesize , pack.window et pack.threads . on dirait que vous n’avez pas besoin d’autres options 🙂

Sans access direct au référentiel et donc incapable d’effectuer un reconditionnement, effectuez un clone superficiel, puis récupérez progressivement tout en augmentant la profondeur.

 git clone YOUR_REPO --depth=1 git fetch --depth=10 ... git fetch --depth=100 git fetch --unshallow //Downloads all history allowing to push from repo 

J’espère que ça peut encore aider quelqu’un.

J’ai résolu le problème en utilisant les étapes suivantes.

  1. Obtention du référentiel extrait du serveur sur mon ordinateur local (en utilisant une copie brute sur ssh)
  2. Reconditionner le référentiel local
    git repack -a -d --window-memory 10m --max-pack-size 20m
  3. Création d’un référentiel vide sur le serveur
    git init --bare
  4. Pousse le référentiel local sur le serveur
  5. Vérifié qu’il est possible de cloner le référentiel du serveur

Cela ne répond pas à la question, mais quelqu’un pourrait le rencontrer: le reconditionnement peut également échouer sur le serveur lorsque pack-objects se terminent par une sorte de killer (comme celui utilisé sur Dreamhost):

 $ git clone project-url project-folder Cloning into project-folder... remote: Counting objects: 6606, done. remote: Compressing objects: 100% (2903/2903), done. error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed 

Sur Dreamhost, cela semble être causé par mmap . Le code de reconditionnement utilise mmap pour mapper le contenu de certains fichiers en mémoire, et comme le suppresseur de mémoire n’est pas assez intelligent, il compte les fichiers mappés comme mémoire utilisée, tuant le processus Git lorsqu’il essaie de mmap un fichier volumineux.

La solution consiste à comstackr un fichier binary Git personnalisé avec le support mmap désactivé ( configure NO_MMAP=1 ).

J’utilise la version 1.7.0.4 de git et accepte cette commande. Il est possible que git version 1.6 n’accepte pas cette commande.

Essayez de créer un nouveau référentiel avec des commits aléatoires. Ensuite, remballez-le avec cette commande.

J’ai eu le même problème sur Ubuntu 14.10 avec git 2.1.0 sur un repository privé de github.com. (Le routeur d’entreprise est suspecté! Fonctionne sur différents réseaux wifi, sauf sur le lieu de travail)

 * GnuTLS recv error (-54): Error in the pull function. * Closing connection 2jects: 31% (183/589) error: RPC failed; result=56, HTTP code = 200 fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header 

Ma solution était de git cloner en utilisant ssh (j’ai configuré au préalable des clés ssh *), comme ceci:

clone git https://github.com/USERNAME/REPOSITORYNAME.git

devient:

git clone git@github.com: USERNAME / REPOSITORYNAME.git

*: (Génération d’une clé ssh)

ssh-keygen -t rsa -C “your_email_address_registered_with_github@domain.com”

Ensuite, connectez-vous à github, dans les parameters, importez les clés ssh et importez-le depuis ~ / .ssh / id_rsa.pub.