Le repack du dépôt Git échoue

Question

J'ai un dépôt git résidant sur un serveur avec une mémoire limitée. Lorsque j'essaie de cloner un dépôt 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 repacker le dépôt d'origine (conformément à la directive ce message du forum ). Mais au lieu de repacker le dépôt, 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.

Answer 1

Votre solution vous a permis d'obtenir une copie fonctionnelle localement et à distance, mais elle posera à nouveau des problèmes lorsque le référentiel distant décidera de se repacker à nouveau. Heureusement, vous pouvez définir des options de configuration qui réduiront la quantité de mémoire nécessaire pour le repacking dans les deux dépôts -- ces options transforment essentiellement les paramètres de ligne de commande que vous avez ajoutés en options par défaut lors du repacking. Ainsi, vous devriez vous connecter à distance, changer dans le référentiel et faire :

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

Vous pouvez faire de même sur votre référentiel local. (Incidemment, je suppose que soit votre référentiel est très grand, soit ce sont des machines avec peu de mémoire - ces valeurs me semblent très basses).

Pour ce que ça vaut, quand on obtient des échecs de malloc lors du repacking muy de grands dépôts dans le passé, j'ai également changé les valeurs de core.packedgitwindowsize , core.packedgitlimit , core.deltacachesize , pack.deltacachesize , pack.window y pack.threads mais il semble que vous n'ayez pas besoin d'autres options :)

Answer 2

N'ayant pas d'accès direct au référentiel et ne pouvant donc pas effectuer un repack, effectuer un clone peu profond puis récupérer progressivement en augmentant la profondeur m'a aidé.

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 cela peut encore aider quelqu'un.

Answer 3

J'ai résolu le problème en suivant les étapes suivantes.

1. J'ai récupéré le référentiel du serveur sur ma machine locale (en utilisant une copie brute via ssh).
2. Repacked the local repository
   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 vers le serveur
5. Vérifié qu'il est possible de cloner le référentiel du serveur

Answer 4

Cela ne répond pas à la question, mais quelqu'un pourrait y être confronté : le repacking pourrait également échouer sur le serveur lorsque pack-objects est terminé par une sorte de tueur 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 du repack utilise mmap pour mapper le contenu de certains fichiers en mémoire, et comme le tueur de mémoire n'est pas assez intelligent, il compte les fichiers mappés comme de la mémoire utilisée, tuant le processus Git lorsqu'il essaie de mmap un fichier volumineux.

La solution est de compiler un binaire Git personnalisé avec mmap désactivé ( configure NO_MMAP=1 ).

Answer 5

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

Essayez de créer un nouveau dépôt avec quelques commits aléatoires. Puis repackez-le avec cette commande.