Voici donc ce que j'ai découvert jusqu'à présent :je n'ai trouvé aucune documentation sur ces '.tmp-XXXX-pack' cachés dans le .git/objects/pack dossier. Tous les autres sujets que je peux trouver concernent non cachés fichiers avec tmp_ préfixe dans le même dossier. Les cachés sont également clairement créés lors de l'action de remballage et il est possible qu'ils restent également bloqués. Je ne peux pas confirmer si cela est toujours possible dans git 2.3.0 (que j'ai mis à jour depuis), mais au moins l'espace disque requis ne semble pas avoir changé dans cette nouvelle version - il ne peut toujours pas terminer gc /reconditionner. En supprimant ces fichiers .tmp, j'ai pu récupérer mes derniers 4 Go et git semble toujours se comporter correctement par la suite - vos résultats peuvent cependant varier, alors assurez-vous d'avoir une sauvegarde avant de faire cela . Enfin, même 4 Go n'étaient pas suffisants pour remballer avec gc --agressive . Mon .git dossier est de 1,1 Go après le nettoyage, mon référentiel complet est de 1,7 Go. Donc 2x la taille de votre référentiel n'est peut-être pas suffisant pour git gc , même avec l'option agressive (qui devrait économiser de l'espace). J'ai donc dû d'abord récupérer plus d'espace ailleurs.
Enfin, voici ce que j'ai maintenant dans mon script de nettoyage (que je pense être une bonne idée d'appeler à partir d'une tâche cron) :
#!/bin/bash
set -e
#git gc or remove tmp if that fails (because out of disk space)
git gc --aggressive --prune=now || rm -f .git/objects/*/tmp_* && rm -f .git/objects/*/.tmp-*
Scénario similaire (environ 2,3 G disponibles), sauf git gc lui-même échouerait également avec fatal: Unable to create '/home/ubuntu/my-app-here/.git/gc.pid.lock': No space left on device
Ce qui a fonctionné était de git prune d'abord, puis exécutez le gc.