Réception depuis l'origine avec des branches distantes supprimées ?

Question

Lorsque je fais git fetch origin et qu'origin a une branche supprimée, cela ne semble pas la mettre à jour dans mon référentiel. Lorsque je fais git branch -r, cela affiche toujours origin/DELETED_BRANCH.

Comment puis-je résoudre ce problème?

Answer 1

Vous devez faire ce qui suit

git fetch -p

L'argument -p ou --prune mettra à jour la base de données locale des branches distantes.

Answer 2

De http://www.gitguys.com/topics/adding-and-removing-remote-branches/

Après que quelqu'un ait supprimé une branche d'un dépôt distant, git ne supprimera pas automatiquement les branches du dépôt local lorsqu'un utilisateur fait un git pull ou git fetch. Cependant, si l'utilisateur souhaite supprimer toutes les branches de suivi de leur dépôt local qui ont été supprimées dans un dépôt distant, ils peuvent taper :

git remote prune origin

À noter, le paramètre -p de git fetch -p signifie en réalité "prune".
De toute manière que vous choisissiez, les branches distantes inexistantes seront supprimées de votre dépôt local.

Answer 3

Vous devez faire ce qui suit

git fetch -p

afin de synchroniser votre liste de branches. Le manuel de git dit

-p, --prune
Après avoir effectué le fetch, supprimez toutes les références de suivi distant qui n'existent plus sur le serveur distant. Les tags ne sont pas soumis à l'élagage s'ils sont téléchargés uniquement en raison du suivi automatique des tags par défaut ou en raison d'une option --tags. Cependant, si les tags sont téléchargés en raison d'un refspec explicite (soit en ligne de commande, soit dans la configuration du serveur distant, par exemple si le serveur distant a été cloné avec l'option --mirror), alors ils sont également soumis à l'élagage.

Personnellement, j'aime utiliser git fetch origin -p --progress car cela affiche un indicateur de progression.

Answer 4

Cela a fonctionné pour moi.

git remote update --prune

Answer 5

Concernant git fetch -p, son comportement a changé dans Git 1.9, et seulement Git 2.9.x/2.10 reflète cela.

Voir commit 9e70233 (13 juin 2016) par Jeff King (peff).
(Fusionné par Junio C Hamano -- gitster -- dans commit 1c22105, 06 juillet 2016)

fetch : documenter que l'élagage se produit avant le fetch

Ceci a été modifié dans 10a6cc8 (fetch --prune : Exécuter l'élagage avant le fetch, 2014-01-02), mais il semble que personne dans cette discussion n'ait réalisé que nous faisions explicitement de la publicité pour l'action "après".

Donc la documentation indique maintenant :

Avant le fetch, supprimer toutes les références de suivi à distance qui n'existent plus sur le distant

Cela est dû à :

Lorsque nous avons une branche de suivi à distance nommée "frotz/nitfol" d'un fetch précédent, et que l'amont a désormais une branche nommée "frotz", le fetch échouerait à supprimer "frotz/nitfol" avec un "git fetch --prune" depuis l'amont. git informerait l'utilisateur d'utiliser "git remote prune" pour résoudre le problème.

Changer la façon dont "fetch --prune" fonctionne en déplaçant l'opération d'élagage avant l'opération de fetch. De cette façon, au lieu d'avertir l'utilisateur d'un conflit, il le corrige automatiquement.