Description : Que signifie « Not enough disk space to clone the repository » ? Les causes possibles d'un dépôt géant et les moyens de travailler sans tout télécharger.
Vous vouliez corriger quelques lignes. L'outil répond qu'il n'y a pas assez d'espace pour cloner le dépôt.
Ce n'est pas le signe d'un programme cassé. C'est l'environnement qui doit recevoir la copie qui manque de place. Les fichiers stockés sur GitHub ne sont pas pour autant effacés.
Dans un cas concret, l'API GitHub indiquait environ 9 Go pour un dépôt. Commander un tournevis et recevoir tout le magasin de bricolage, étagères comprises : voilà l'idée.
Ce que le message prouve
La copie a rencontré un manque de stockage. Le message ne précise ni l'espace libre restant, ni les données déjà téléchargées, ni la part occupée par les fichiers actuels ou leur historique.
Les quelque 9 Go correspondent à une valeur arrondie annoncée par l'API, et non à une mesure du clone local qui a échoué. Les objets téléchargés, les fichiers extraits et l'espace temporaire peuvent représenter des volumes différents.
Pourquoi un dépôt prend autant de place
Git conserve les versions précédentes. De grosses images, sauvegardes ou sorties générées ajoutées autrefois peuvent rester dans l'historique. Un projet qui accumule des articles, des traductions, des images et des fichiers générés peut aussi avoir un dossier de travail volumineux.
Il faut examiner les fichiers présents et les objets historiques séparément pour déterminer le véritable responsable.
GitHub recommande de garder des dépôts de taille raisonnable, avec notamment un maximum recommandé de 10 Go pour le dossier .git sur disque. Ce n'est pas un blocage automatique de tous les clones au seuil des 10 Go, et ce n'est pas nécessairement la même mesure que le champ de taille de l'API.
Ne déménagez pas le dépôt pour un seul fichier
Un nouvel environnement peut résoudre le problème si l'ancien accumulait les fichiers temporaires. Si le dépôt lui-même est énorme, la panne peut se reproduire.
Pour lire ou modifier un fichier isolé, l'API de fichiers de GitHub permet d'éviter un clonage complet, à condition d'avoir les autorisations requises.
Si Git est indispensable, essayez de limiter l'historique et les fichiers récupérés au départ :
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
Cette commande réduit l'historique téléchargé, reporte le chargement du contenu des fichiers et limite l'extraction initiale. Elle ne garantit pas le succès partout ; certaines opérations exigeant l'historique complet seront limitées.
La fausse bonne idée
N'effacez pas l'historique dans la précipitation. Le réécrire peut perturber les collaborateurs, les anciennes références et les automatisations. Mesurez d'abord l'espace libre, les gros fichiers actuels et les objets historiques ; sauvegardez avant tout nettoyage destructeur.
La vraie question
La mission : « Modifier ce fichier. » La logistique prévue : « Transporter un entrepôt de 9 Go. »
Pourquoi déplacer l'entrepôt entier pour récupérer un seul document ? Avant d'acheter un disque plus grand, repensez la manière de récupérer les données.
Sources : recommandations GitHub, gestion des gros fichiers, documentation Git clone.
