web-dev-qa-db-fra.com

Le remballage du référentiel Git échoue

J'ai un référentiel 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, l'erreur suivante apparaît.

hemi@ubuntu:$ git clone ssh://[email protected]/home/hemi/repos/articles
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/
[email protected]'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 reconditionner le référentiel d'origine (selon cet article du forum ). Mais au lieu de remballer le référentiel, il explique 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.

gitrepository
55
midtiby

Votre solution vous fournit une copie de travail localement et à distance, mais causera à nouveau des problèmes lorsque le référentiel distant décide de se reconditionner. Heureusement, vous pouvez définir des options de configuration qui réduiront la quantité de mémoire nécessaire au reconditionnement dans les deux référentiels. Elles constituent essentiellement les paramètres de ligne de commande ajoutés aux options par défaut lors du reconditionnement. Donc, vous devez vous connecter à la télécommande, aller dans le référentiel et faire:

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

Vous voudrez peut-être faire la même chose sur votre référentiel local. (Incidemment, je suppose que votre référentiel est très volumineux ou qu'il s'agit de machines avec peu de mémoire - ces valeurs me paraissent très basses.)

Pour ce qui en vaut la peine, j’ai déjà modifié les valeurs de core.packedgitwindowsize, core.packedgitlimit, core.deltacachesize, pack.deltacachesize, pack.window et pack.threads au cours du reconditionnement de très grands dépôts pas besoin d'options supplémentaires :)

100
Mark Longair

Sans accès direct au référentiel et donc incapable de remballer, effectuer un clone peu profond puis rechercher progressivement tout en augmentant la profondeur m'a été utile. 

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.

19
mmm

J'ai résolu le problème en procédant comme suit.

  1. Le référentiel a été extrait du serveur sur ma machine locale (en utilisant une copie brute sur ssh)
  2. Reconditionné 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. Poussé le référentiel local sur le serveur
  5. Vérifié qu'il est possible de cloner le référentiel du serveur 
15
midtiby

Cela ne répond pas à la question, mais quelqu'un peut le rencontrer: le reconditionnement peut également échouer sur le serveur lorsque pack-objects se termine par un type de destructeur de mémoire (tel que 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 remballage utilise mmap pour mapper le contenu de certains fichiers dans la mémoire et, comme le destructeur de mémoire n’est pas assez intelligent, il compte les fichiers mappés comme de la mémoire utilisée, ce qui tue le processus Git lorsqu’il tente de mmap un fichier volumineux.

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

5
zoul

J'utilise la version 1.7.0.4 de Git et cette commande est acceptée. Il est possible que la version 1.6 de git n'accepte pas cette commande.

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

1
matthias.lukaszek

J'ai eu le même problème sur Ubuntu 14.10 avec git 2.1.0 sur un dépôt privé de github.com. (On craint un routeur d'entreprise! Fonctionne sur un réseau wifi différent, 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, git clone en utilisant ssh (j'ai configuré les clés ssh * au préalable), comme ceci:

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

devient:

git clone [email protected]: USERNAME/REPOSITORYNAME.git

*: (Générer une clé ssh)

ssh-keygen -t rsa -C "[email protected]"

Puis connectez-vous à github, dans les paramètres, importez les clés ssh et importez-le de ~/.ssh/id_rsa.pub.

0
arcol