Desvincular del file fallido

Estoy tratando de hacer un truco y recibo el siguiente error:

Se produjo un error al desvincular el file 'lib / xxx.jar'. ¿Debería intentarlo de nuevo? (y / n)

No importa si selecciono y o n no es posible llegar a un estado en el que pueda tirar o empujar.

Eso generalmente significa que un process todavía está usando ese file específico (todavía tiene un control sobre él)
(en Windows, ProcessExplorer es bueno en el seguimiento de ese tipo de process)

Intenta cerrar tus otros progtwigs y vuelve a intentar tu git pull .

Tenga en count que tiene una alternativa con la variable GIT_ASK_YESNO .


Actualización enero de 2016

Eso debería arreglarse en Git 2.8 (marzo de 2016)

Consulte commit d562102 , commit dcacb1b , commit df617b5 , commit 0898c96 (13 Jan 2016) por Johannes Schindelin ( dscho ) .
(Fusionado por Junio ​​C Hamano – gitster – in commit 3c80940 , 26 de enero de 2016)

fetch : libera los files del package antes de recolectar basura

Antes de auto-gc'ing, debemos asegurarnos de que los files del package se liberen en caso de que necesiten ser reempaquetados y recolectados.

Muchas routes de código que ejecutan " gc --auto " antes de salir guardaban los files empadronados y les dejaban abiertos los descriptores de file, lo que no era compatible con los sistemas que no pueden eliminar los files que están abiertos.
Ahora cierran los packages antes de hacerlo.

Eso soluciona el problema 500 de git-for-widows .

En cuanto a la testing utilizada para validar ese nuevo enfoque , una posible solución alternativa (ya que Git 2.8 aún no está disponible) sería boost artificialmente gc.autoPackLimit .

 git config gc.autoPackLimit 10000 git fetch git config gc.autoPackLimit 50 # default value 

git 2.8.4 (junio de 2016) menciona el problema 755 que también debería aliviar el problema ( commit 2db0641 ):

Asegúrese de que los processs temporales no henetworkingen los identificadores temporales de files

Esta es una respuesta específica de Windows, por lo que soy consciente de que no es relevante para ti … Solo lo estoy incluyendo para el beneficio de futuros buscadores.

En mi caso, fue porque estaba ejecutando Git desde una línea de command no elevada. "Ejecutar como administrador" lo solucionó por mí.

Para mí, fue porque Visual Studio intentaba volver a cargar todos los files modificados de la extracción. Haga que el estudio visual se actualice, luego ejecute git gc .

En Windows usando GitHub para Windows, recibí un error similar en el shell al ejecutar git gc :

 Unlink of file '.git/objects/pack/pack-0b40ae7eae9b83edac62e19c07ff7b4c175244f6.idx' failed. Should I try again? (y/n) 

Lo resolví cerrando la GUI de GitHub.

Cerré Visual Studio y Rubymine y no volví a get el error. Uno de ellos fue el culpable.

Esto fue causado en mi caso por SimpLESS, el comstackdor LESS. Tienes que cerrarlo en la bandeja del sistema.

Intente reiniciar Apache u otro server web, ya que puede haber bloqueado algunos de sus files.

Cierre su IDE y luego haga git pull . Funcionará.

También tengo este problema, pero descubrí que era el UltraEdit en el path, ya que utilicé UE para organizar y editar mi espacio de trabajo eclipse ~~

Tal vez porque el UE tiene un control sobre la versión anterior del file específico, Git no pudo desvincularlo.

Después de cerrar UltraEdit, el problema nunca volvió a suceder.

El problema es porque estás teniendo algún progtwig que maneje estos files. Tengo una sugerencia de que deberías usar el Desbloqueador para encontrar el progtwig que lo está manejando:

Unlocker

He tenido que pasar esto en Windows XP, tanto con el post pegado en un bucle, y ser capaz de despejarme respondiendo.

La ocurrencia de atrapado en un bucle se borró al cerrar la Git-GUI. (Estaba ejecutando git merge -i en un shell bash).

Las otras ocurrencias ocurrieron posiblemente debido a la gran cantidad de files en mi repository. Sucedió principalmente con los files .cod, que más tarde excluiré del control de la versión. (Tengo una razón para rastrearlos inicialmente.) Creo que la causa podría estar relacionada con la velocidad a la que Git usa los identificadores de file.

Me pregunto si el problema de la capacidad para ser resuelto está relacionado con Windows, ya que dos carteles anteriores mencionaron Windows y nadie ha dicho que tienen el problema con otros sistemas operativos.

Tenía PHPStorm abierto, lo cerré y todo estaba bien.

Tuve el mismo problema y cerré todos los progtwigs relacionados desde el Administrador de tareas de Windows. Sin embargo, todavía no estaba funcionando. La parte interesante es que ejecuté "Git rebase" en lugar de "Git pull" y ¡funcionó!