Git pull: errore: voce pippo non aggiornata. Impossibile unire

Sto cercando di aggiornare il mio repository da un ramo remoto e continuo a ricevere questo errore quando eseguo un "git pull". Non ho apportato modifiche locali e, anche se l'ho fatto, non ho bisogno di mantenerle.

Ho provato:

git reset --hard

e ho lo stesso problema

L'unica cosa che sembra funzionare è eliminare il file incriminato e provare di nuovo un git pull.

Ho anche provato git stashseguito da un file git pull. No go.

modifica: utilizzando PortableGit-1.6.4-preview20090729 in modo che eventuali bug precedenti con errori spuri dovrebbero essere corretti.

Ci sono un paio di modi per risolvere questo problema, ma ho scoperto che git stash funziona bene per me. Mette temporaneamente le modifiche locali in un altro posto. Quindi puoi tirare, per afferrare le ultime modifiche. E poi puoi ripristinare le modifiche locali.

Proprio come questo:

$ git pull
...
...
file your_file.rb not up to date, cannot merge.

$ git stash
$ git pull
$ git stash pop

Ciò può accadere se aggiorni l'indice per ignorare determinati file:

git update-index --assume-unchanged <file>

e poi per esempio controlla qualche altro ramo:

git checkout <branch>
> error: Entry '<file>' not uptodate. Cannot merge.

Forzare l'aggiornamento dell'indice risolve il problema:

git update-index --really-refresh
<file>: needs update

Seguito da:

git reset --hard 

E poi tutto dovrebbe tornare alla normalità.

Questo tipo di problema è spesso causato dal tentativo di eseguire il pull da un repository che ha due nomi di file che differiscono solo nel caso. Se sei su FAT, NTFS in modalità senza distinzione tra maiuscole e minuscole (essenzialmente, ogni volta che viene utilizzato in Windows), o HFS + in modalità senza distinzione tra maiuscole e minuscole, e hai due file "foobar" e "FOOBAR", Git ne vedrà due distinti file, ma il filesystem ne vedrà solo uno, il che causerà tutti i tipi di problemi. Git effettuerà il checkout, ad esempio "FOOBAR", e quindi il checkout "foobar", che il filesystem vede semplicemente sostituire il contenuto di "FOOBAR" ma lasciandolo al suo posto. Ora a Git, sembra che "FOOBAR" sia stato sostituito con il contenuto di "foobar", e "foobar" non c'è più.

Ci sono due diverse manifestazioni di questo problema di base. Uno è quando il tuo repository contiene effettivamente due file che differiscono solo sul caso. In questo caso, è necessario lavorare su un file system che fa distinzione tra maiuscole e minuscole o sarà necessario modificare il repository per assicurarsi che non si verifichino collisioni di questo tipo; un file system senza distinzione tra maiuscole e minuscole semplicemente non può memorizzare il contenuto di questo repository.

Un caso diverso che puoi risolvere è quando si verifica una ridenominazione che cambia il caso del file. Supponiamo, ad esempio, che il repository Git contenga una ridenominazione da "EXAMPLE" a "example". Prima che Git controlli la nuova versione, proverà a verificare che non stia sovrascrivendo alcuni file esistenti che hai sul tuo disco. Poiché pensa che "esempio" sia un nuovo nome di file, chiederà al filesystem se esiste, e il filesystem vedrà "ESEMPIO" e dirà di sì, quindi Git rifiuterà di controllare la nuova versione poiché pensa che sovrascriverà file non tracciati. In questo caso, se non hai modifiche locali che ti interessano, un semplice filegit reset --hard <revision-to-checkout>sarà generalmente sufficiente per superare il problema e passare alla nuova revisione. Cerca solo di ricordarti di non rinominare i file con altri nomi che differiscono solo nel caso in cui ti trovi su un file system senza distinzione tra maiuscole e minuscole, poiché causerà problemi come questo.

Per ulteriori approfondimenti sul post di @Brian Campbell (perché neanche il reset hard non ha funzionato) voglio sottolineare un caso limite che mi stava fermando.

Avevo spostato un file OldFilein una cartella diversa e l'ho rinominato NewFile. Ho quindi contrassegnato il file come assume-unchanged.

Questo mi impediva di cambiare ramo e non c'erano scorte da salvare o impegnarsi per spingere. Il problema era che non avevo eseguito il commit di questa modifica del file con un nuovo nome prima di impostare il assume-unchangedflag. Quindi l'ho impostato di nuovo su no-assume-unchanged, eseguito il commit, quindi l'ho reimpostato su assume-unchangede ho potuto cambiare di nuovo i rami.

In generale, ciò significa che sono presenti modifiche nei file locali che non sono state salvate nel repository locale. Puoi anche vedere questa domanda di stackoverflow per maggiori dettagli.

Stavo riscontrando un problema simile (Windows 10): ero acceso branchAe volevo andare a master. Ho avuto alcune modifiche non autorizzate, quindi prima ho git stashpoi git checkout -f masterma ho ancora ottenuto il Entry 'fileName' not uptodate. Cannot merge.

git status non mostrava nulla da commettere.

Alla fine ho semplicemente rimosso il file manualmente e sono stato in grado di andare all'altro ramo (che ovviamente ha fatto tornare il mio file) quindi immagino che da qualche parte ci sia stato un bug all'interno di git.

Potrebbe essere un problema anche con i permessi dei file. Git esegue anche il controllo delle versioni, a meno che config non dica diversamente. Aggiungendo solo questa risposta per le persone che hanno quasi ma non il problema simile.

Vale la pena provare:

Potresti impostare, solo per questo aggiornamento, il parametro configcore.trustctime su false?

core.trustctime

Se false, le differenze ctime tra l'indice e la copia di lavoro vengono ignorate; utile quando l'ora di modifica dell'inode viene regolarmente modificata da qualcosa al di fuori di Git (crawler del file system e alcuni sistemi di backup).

Aggiungo la mia risposta perché nessuno degli altri lo menziona. Nel mio caso ciò è accaduto dopo aver aggiunto nuovi file all'indice con il -Nflag, quindi aggiungendoli all'indice senza aggiungere il loro contenuto. In questo stato, fare git stashproduce questo errore.

Ho avuto lo stesso errore, dopo una situazione in cui git statusdetto new file: foo.cppper un file non aggiunto all'area di staging. cioè sotto l'intestazione "Modifiche non organizzate per il commit". Molto strano, questo di solito non accade.

Soluzione: git add foo.cppe poi ha git stashfunzionato di nuovo.

Stavo cercando di eseguire git merge --abort. Il comando git restore your_file ha risolto il problema per me