Dissocier le fichier a échoué
J'essaie de tirer un git et j'obtiens l'erreur suivante:
La dissociation du fichier 'lib/xxx.jar' a échoué. Devrais-je essayer à nouveau? (y/n)
Peu importe si je sélectionne y ou n, il n'est pas possible d'obtenir un état où je peux tirer ou pousser.
Cela signifie généralement qu'un processus utilise toujours ce fichier spécifique (a toujours une poignée dessus)
(sous Windows, ProcessExplorer maîtrise bien ce genre de processus)
Essayez de fermer vos autres programmes et essayez à nouveau votre git pull.
Notez que vous avez une alternative avec la variable GIT_ASK_YESNO .
Mise à jour janvier 2019:
Cela devrait être encore plus résolu, avec Git 2.21 (Q1 2019), car "git gc" et "git repack" ne fermaient pas les fichiers packs ouverts qu’ils trouvaient inutiles avant de les supprimer, ce qui ne fonctionnait pas sur une plateforme incapable de supprimer un fichier ouvert. fichier.
.__ Ceci a été corrigé.
Voir commit 5bdece0 (15 déc. 2018) de Johannes Schindelin (dscho) .
(Fusion par Junio C Hamano - gitster - dans commit 5104f8f , 18 janvier 2019)
gcrepack: packs de publication en cas de besoinSous Windows, les fichiers ne peuvent pas être supprimés ni renommés s'il existe toujours des descripteurs détenus par un processus.
Pour remédier à cela, nous avons introduit la fonctionclose_all_packs().Plus tôt, nous nous sommes assurés que les packs sont publiés juste avant que
git gcsoit créé, au cas oùgcsouhaite supprimer les packs dont vous n'avez plus besoin.Mais ce développeur a oublié que
gca également besoin de lâcher des paquets, par exemple. lors de la consolidation de tous les packs via l'option--aggressive.De même,
git repack -dveut supprimer les packs obsolètes et doit donc fermer tous les descripteurs de pack.
Mise à jour janvier 2016
Cela devrait être corrigé dans Git 2.8 (mars 2016) (et voir Git 2.19, T3 2018 ci-dessous)
Voir _/commit d562102 , commit dcacb1b , commit df617b5 , commit 0898c96 (13 janv. 2016) de Johannes Schindelin (dscho) .
(Fusion par Junio C Hamano - gitster - dans commit 3c80940 , 26 janv. 2016)
fetch: publier les fichiers du pack avant la récupération de placeAvant la création automatique, nous devons nous assurer que les fichiers du pack sont publiés au cas où ils devraient être reconditionnés et ramassés.
De nombreux chemins de code qui exécutent "
gc --auto" avant de quitter les fichiers de paquets conservés mappés et qui leur laissaient les descripteurs de fichiers ouverts, ce qui n'était pas pratique pour les systèmes qui ne peuvent pas supprimer les fichiers ouverts.
Ils referment maintenant les sacs avant de le faire.
Cela corrige git-for-widows numéro 500 .
En examinant le test utilisé pour valider cette nouvelle approche , une solution de contournement possible (puisque Git 2.8 n'est pas encore disponible) serait d'élever artificiellement gc.autoPackLimit.
git config gc.autoPackLimit 10000
git fetch
git config gc.autoPackLimit 50 # default value
git 2.8.4 (juin 2016) mentionne effectivement numéro 755 , ce qui devrait également résoudre le problème ( commit 2db0641 ):
Assurez-vous que les descripteurs de fichiers temporaires ne sont pas hérités par les processus enfants
En fait, le git-for-windows numéro 500 mentionné ci-dessus est vraiment corrigé avec Git 2.19, Q3 2018.
Voir " Git - La dissociation du fichier .idx et du .pack a échoué (le seul descripteur de processus appartenant à ce fichier est git.exe) "
Ceci est une réponse spécifique de Windows, donc je suis conscient que cela ne vous concerne pas ... je l'inclue simplement pour le bénéfice des futurs chercheurs.
Dans mon cas, c'était parce que j'exécutais Git à partir d'une ligne de commande non élevée. "Exécuter en tant qu'administrateur" l'a corrigé pour moi.
Pour moi, c’est parce que Visual Studio essayait de recharger tous les fichiers modifiés à partir du pull. Faites actualiser Visual Studio, puis exécutez git gc.
Sous Windows utilisant GitHub pour Windows, une erreur similaire s'est produite dans le shell lors de l'exécution de git gc:
Unlink of file '.git/objects/pack/pack-0b40ae7eae9b83edac62e19c07ff7b4c175244f6.idx' failed. Should I try again? (y/n)
Je l'ai résolu en fermant l'interface graphique de GitHub.
Essayez de redémarrer Apache ou un autre serveur Web, car certains de vos fichiers auraient pu être verrouillés.
Fermez votre IDE puis faites git pull. Ça va marcher.
Fermé Visual Studio et Rubymine et ne plus avoir l'erreur. L'un d'eux était le coupable.
Cela a été causé dans mon cas par SimpLESS, le compilateur LESS. Vous devez le fermer dans le systray.
J'ai aussi ce problème, mais j'ai découvert que c'était l'UltraEdit qui me gênait depuis que j'ai utilisé l'UE pour organiser et éditer mon espace de travail Eclipse ~~
Peut-être que parce que l'UE possède un descripteur sur l'ancienne version d'un fichier spécifique, Git ne pourrait pas le dissocier.
Après avoir fermé UltraEdit, le problème ne s'est jamais reproduit.
C'est ce qui est arrivé sous Windows XP, avec le message bloqué dans une boucle et la possibilité d'être effacé en répondant.
L'occurrence de blocage dans une boucle a été effacée en fermant Git-GUI. (Je courais git merge -i dans un shell bash.)
Les autres occurrences sont probablement dues au grand nombre de fichiers de mon référentiel. Cela s'est produit principalement avec les fichiers .cod, que j'ai par la suite exclus du contrôle de version. (J'ai une raison de les suivre initialement.) Je pense que la cause pourrait être liée à la vitesse à laquelle Git utilise les descripteurs de fichiers.
Je me demande si le problème de la possibilité d'être réglé par la réponse est lié à Windows, car deux affiches précédentes ont mentionné Windows et personne n'a déclaré avoir le problème avec d'autres systèmes d'exploitation.
Le problème vient du fait que certains programmes traitent ces fichiers ..__ Je suggère que vous utilisiez Unlocker pour trouver le programme qui le gère:
PHPStorm était ouvert, fermé et tout allait bien.
Aucune des réponses ci-dessus ne fonctionne pas pour moi, mais je lance la commande git gc avec l'option force, ce qui a résolu mon cas.
'git gc --force'
[Windows 7, Exécuter en tant qu'administrateur => Invite de commande]
J'ai eu le même problème et j'ai fermé tous les programmes connexes à partir du gestionnaire de tâches Windows. Cependant, cela ne fonctionnait toujours pas ... La partie intéressante est que j'ai lancé "Git rebase" au lieu de "Git pull" et cela a fonctionné!