Scollegamento del file non riuscito

Sto provando a fare un pull git e ottengo il seguente errore:

Scollegamento del file 'lib / xxx.jar' non riuscito. Dovrei riprovare? (Y / n)

Non importa se seleziono y o n non è possibile raggiungere uno stato in cui posso tirare o spingere.

Questo di solito significa che un processo sta ancora utilizzando quel file specifico (ha ancora un handle su di esso)
(su Windows,ProcessExplorer è bravo a tenere traccia di quel tipo di processo)

Prova a chiudere gli altri programmi e riprova git pull.

Nota che hai un'alternativa con la GIT_ASK_YESNOvariabile .

Aggiornamento gennaio 2019:

Ciò dovrebbe essere ancora più corretto, con Git 2.21 (Q1 2019), in quanto " git gc" e " git repack" non hanno chiuso i file di pacchetto aperti che hanno trovato non necessari prima di rimuoverli, che non funzionavano su una piattaforma incapace di rimuovere un file aperto.
Questo è stato corretto.

Vedi commit 5bdece0 (15 dic 2018) di Johannes Schindelin ( dscho) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 5104f8f , 18 gen 2019)}

gc/ repack: rilasciare i pacchetti quando necessario

Su Windows, i file non possono essere rimossi o rinominati se ci sono ancora handle gestiti da un processo.
Per rimediare, abbiamo introdotto la close_all_packs()funzione.

In precedenza, ci siamo assicurati che i pacchetti fossero rilasciati poco prima della git gcgenerazione, nel caso in cui gcvolessero rimuovere i pacchetti non più necessari.

Ma questo sviluppatore ha dimenticato che gcè necessario lasciar perdere i pacchetti, ad esempio quando si consolidano tutti i pacchetti tramite l' --aggressiveopzione.

Allo stesso modo, git repack -dvuole eliminare i pacchetti obsoleti e quindi deve chiudere anche tutti gli handle dei pacchetti.

Aggiornamento gennaio 2016

Questo dovrebbe essere risolto in Git 2.8 (marzo 2016) (e vedi Git 2.19, Q3 2018 di seguito)

Vedi commit d562102 , commit dcacb1b , commit df617b5 , commit 0898c96 (13 gennaio 2016) di Johannes Schindelin ( dscho) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 3c80940 , 26 gennaio 2016)}

fetch: rilasciare i file del pacchetto prima della raccolta dei rifiuti

Prima di auto-gc, dobbiamo assicurarci che i file del pacchetto vengano rilasciati nel caso in cui debbano essere reimballati e raccolti.

Molti codepath che eseguono " gc --auto" prima di uscire mantengono i file pack mappati e lasciano aperti i descrittori dei file, il che non è amichevole con i sistemi che non possono rimuovere i file aperti.
Ora chiudono i pacchetti prima di farlo.

Ciò risolve il git-for-widowsproblema 500 .

Guardando il test usato per validare quel nuovo approccio , una possibile soluzione alternativa (dato che Git 2.8 non è ancora uscito) sarebbe quella di aumentare artificialmente gc.autoPackLimit.

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

git 2.8.4 (giugno 2016) menziona il problema 755 che dovrebbe anche alleviare il problema ( commit 2db0641 ):

Assicurarsi che gli handle di file temporanei non siano ereditati dai processi figlio

In realtà, il git-for-windowsproblema 500 menzionato sopra è stato risolto con Git 2.19, Q3 2018.
Vedi " Git - Scollegamento del file .idxe .packerrore (l'unico processo gestito da questo file è git.exe) "

Questa è una risposta specifica per Windows, quindi sono consapevole che non è rilevante per te ... La sto solo includendo a beneficio dei futuri ricercatori.

Nel mio caso, è stato perché stavo eseguendo Git da una riga di comando non elevata. "Esegui come amministratore" risolto il problema per me.

Per me, è stato perché Visual Studio stava cercando di ricaricare tutti i file modificati dal pull. Aggiorna Visual Studio, quindi esegui git gc.

Su Windows utilizzando GitHub per Windows, ho riscontrato un errore simile nella shell durante l'esecuzione git gc:

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

L'ho risolto chiudendo la GUI di GitHub.

Prova a riavviare Apache o altri server Web poiché potrebbe aver bloccato alcuni dei tuoi file.

Chiuso Visual Studio e Rubymine e non si è verificato nuovamente l'errore. Uno di questi era il colpevole.

Chiudi il tuo IDE quindi fai git pull. Funzionerà.

Ho anche questo problema, ma ho scoperto che era UltraEdit in mezzo, poiché ho usato UE per organizzare e modificare il mio spazio di lavoro eclissi ~~

Forse perché l'UE ha un handle sulla vecchia versione di un file specifico, Git non ha potuto scollegarlo.

Dopo aver chiuso UltraEdit, il problema non si è mai più verificato.

Questo è stato causato nel mio caso da SimpLESS, il compilatore LESS. Devi chiuderlo nel systray.

Il problema è perché stai avendo qualche programma che gestisce questi file. Ho un suggerimento che dovresti usare Unlocker per trovare il programma che lo sta gestendo:

Unlocker

Ho avuto questo accadere su Windows XP, sia con il messaggio bloccato in un ciclo, sia potendo essere cancellato rispondendo.

L'occorrenza bloccata in un loop è stata cancellata chiudendo la Git-GUI. (Stavo eseguendo git merge -i in una shell bash.)

Le altre occorrenze si sono verificate probabilmente a causa dell'elevato numero di file nel mio repository. È successo principalmente con i file .cod, che in seguito escludo dal controllo della versione. (Ho un motivo per rintracciarli intenzionalmente.) Credo che la causa potrebbe essere correlata alla velocità con cui Git utilizza gli handle di file.

Mi chiedo se il problema che può essere risolto rispondendo sia correlato a Windows, poiché due poster precedenti hanno menzionato Windows e nessuno ha affermato di avere il problema con altri sistemi operativi.

Avevo PHPStorm aperto, chiuso e tutto andava bene.

Ho avuto lo stesso problema e ho chiuso tutti i programmi correlati da Task Manager di Windows. Tuttavia, non funzionava ancora. La parte interessante è che ho eseguito "Git rebase" invece di "Git pull" e ha funzionato!

Nessuna delle risposte precedenti non funziona per me, ma eseguo il comando git gc con l'opzione force e il mio caso è stato risolto.

'git gc --force'

[Windows 7, Esegui come amministratore => Prompt dei comandi]

Prova a eseguire l'editor della riga di comando in modalità amministrativa ed esegui comando. Aiuta e risolve il problema. :)

Nel mio caso avevo un vecchio metodo di potatura dei tag che causava il problema. L'ho risolto annullando l'originale:

git config --global --unset remote.origin.fetch '\+refs/tags/\*:refs/tags/\*'

quindi aggiungendo questo per eliminare i rami eliminati sul server:

git config --global fetch.pruneTags true

Ho riscontrato lo stesso errore e risolto chiudendo l'eclissi e tirando di nuovo mentre il file veniva utilizzato.