Résoudre l’erreur "objet file … is empty"

Comment sortir de cette impasse ?

Pas besoin de vous précipiter à supprimer le dossier et recloner complètement ton projet. Les objets corrompus ont probablement été déjà partagés et peuvent être récupérés pour remettre d’aplomb votre projet.

Pour régler le problème, nous devons procéder en trois étapes :

1. D’abord, supprimer les objets problématiques ;
2. Ensuite, récupérer ces objets dans leur version valide depuis le dépôt distant ;
3. Enfin, vérifier le bon état de notre dépôt.

Commençons avec la purge des objets. La commande suivante est valable dans un environnement équivalent Linux (Linux, WSDL, Git bash, MacOS). Pour Windows (Powsershell et consorts), je vous laisse chercher par vous même 😉.

# Recherche les fichiers vides dans le répertoire `.git/objects`
# et demande leur suppression
find .git/objects/ -type f -empty -delete

Une fois les objets vides purgés, on peut procéder à la récupération de leur version non corrompue avec la commande fetch :

# L’option `-p` nettoie au passage les référence locales
# qui n’existent plus sur le dépôt distant
git fetch -p

Enfin, on utilise la commande fsck qui sert à vérifier la connectivité et l’intégrité des objets dans la base de données Git (ie. le répertoire .git/objects) :

# L’option `--full` vérifie en plus les objets dit "alternatifs" comme les archives.
git fsck --full

Cette dernière commande va produire un rapport, probablement avec des informations de commits ou blob non finalisés (dangling). Si le message d’erreur initial ne réapparait pas, c’est que le dépôt est de nouveau opérationnel. Vous pouvez reprendre le cours normal de votre travail !

L’opération n’a pas fonctionné

Il se peut que cette procédure ne fonctionne pas, par exemple si les objets concernés n’ont pas été partagés avant d’être corrompus. À ce moment là, une solution plus radicale est nécessaire, et les commits en cours locaux non partagés seront perdus. Nuançons toutefois cette perte : vos fichiers projet (hors Git) ne sont pas corrompus, gardez-les dans un coin pour éventuellement faire du copier/coller.

L’idée ici est donc de supprimer le dépôt local et de recloner.

Si vous avez des fichiers à préserver, je vous recommande de garder le répertoire projet, en lui donnant un autre nom par exemple :

cd ..
mv REPERTOIRE_PROJET COPIE_REPERTOIRE_PROJET

Reste alors à récupérer à nouveau le projet depuis le dépôt distant :

git clone URL_DISTANTE REPERTOIRE_PROJET

Cette solution est plus contraignante, mais elle est rapide et efficace. Vous pouvez toutefois tenter une autre approche.

Alternative : suppression du dépôt local

Si vous avez de nombreuses modifications qui risquent d’être pénibles à repliquer, vous pouvez choisir de conserver votre répertoire projet en l’état et de ne remettre d’aplomb que le dépôt local Git, ou dit autrement, le sous-répertoire .git. Notez que si vous avez une configuration locale utile à votre projet, vous devrez la remettre en état à la fin de l’opération.

On commence par la suppression du répertoire :

rm -rf .git

Ensuite, on réinitialise le dépôt local avec Git:

git init

On définit l’URL du dépôt distant et on récupère l’historique projet :

git remote add origin  URL-DU-DEPOT
# Vous pouvez choisir de récupérer une autre branche que `main` (`master` par exemple)
git fetch origin main

On se positionne sur la branche dont on a récupéré l’historique pour pouvoir reprendre notre travail :

git switch main

Et voilà, le tour est joué. Évidemment, ce scenario peut produire des situations de conflits/divergences. Dans ce cas, la commande stash peut s’avérer utile.