Résoudre l'erreur "shallow update not allowed" de Git

Vous avez changé l'origine du dépôt distant de votre projet et impossible de pousser votre code ? Voici les solutions !

Résoudre l'erreur "shallow update not allowed" de Git

Si au détour d'un "git push", votre terminal Git s'est mis à protester avec l'erreur suivante :

"Remote rejected (shallow update not allowed)"

Alors je vais vous expliquer d'où vient le problème, ce qu'est un shallow clone et je vais vous donner les solutions dans cet article !

L'erreur

D'abord il faut savoir qu'un "shallow clone" n'est pas une erreur, mais bel et bien une fonctionnalité de Git !

Lorsque l'on clone un dépôt, pour X ou Y raison (le déploiement par exemple), on a tendance à utiliser la simple commande "git clone [url]" afin de récupérer le projet.

Mais certains projets, notamment les plus anciens, ont parfois un historique si conséquent que récupérer l'entièreté de ce dernier, avec toutes les modifications répertoriées depuis la création du projet peut considérablement ralentir le processus.

Il est donc possible de spécifier un paramètre supplémentaire "--depth <version>" pour spécifier la profondeur d'historique que l'on souhaite récupérer en même temps que le clone du projet.

Comme l'historique n'est pas complet, on appelle cela un "shallow clone" (ou un clone superficiel en français), et donc s'il vous vient l'idée de modifier le code et de pousser les modifications sur une origine différente de celle de départ, alors vous aurez l'erreur en question.

git clone [url] --depth 1
git remote set-url origin [new_url]
git push origin master
-> Remote rejected (shallow update not allowed)

Si vous n'êtes pas sûr d'avoir récupéré un projet superficiel, il vous suffit d'aller regarder à l'intérieur du .git, si c'est le cas vous aurez un fichier nommé "shallow" dans le dossier !

À noter que parfois un projet se retrouve dans un état de "shallow clone" pour une raison totalement différente, mais les solutions sont les mêmes.

Les solutions

Il existe deux solutions, l'une "regénérative", et l'autre "dégénérative", il faudra donc choisir celle qui correpond le mieux à votre cas d'usage.

Réparer l'historique

Si vous faite évoluer le projet actuel et que vous souhaitez garder l'historique pour garder une traçabilité du code réalisé, mais simplement changer de dépôt distant, alors vous pourrez récupérer tout l'historique manquant avec la commande suivante :

git remote add old-origin [old_url]
git fetch --unshallow old-origin
...
Ensuite vous pourrez continuer vos opérations comme si de rien n'était.

Repartir de zéro

Si jamais votre projet de départ n'était qu'un projet d'exemple (un boilerplate), ou bien si la solution précédente n'a pas fonctionné car une modification a désynchronisé votre version locale avec la version d'origine, vous pourrez simplement réinitialiser le projet git, comme ceci :

rm -r .git
git init
git remote add origin [url]
...

Attention, vous l'aurez compris, cette méthode est destructive et vous perdrez tout l'historique mais également la configuration du projet git, néanmoins votre copie actuelle du code restera intacte !

J'espère que cet article vous aura été utile, et à bientôt sur le blog !

Les articles les plus populaires du blog

Envie de continuer à lire des articles autour du développement web (entre autres) ? Voici la sélection des articles de mon blog les plus lus par la communauté !

Voir la sélection 🚀

Recevez les articles de la semaine par e-mail pour ne rien manquer !

S'abonner à la newsletter 📧
Mes formations disponibles 🎓  -5% inclus pour les lecteurs du blog

À propos de l'auteur

Hello, je suis Nicolas Brondin-Bernard, ingénieur web indépendant depuis 2015 passionné par le partage d'expériences et de connaissances.

Aujourd'hui je suis aussi formateur pour développeurs web juniors, tu peux me contacter sur nicolas@brondin.com, sur mon site ou devenir membre de ma newsletter pour ne jamais louper le meilleur article de la semaine et recevoir des offres exclusives !


Photo par Phil Shaw sur Unsplash