Git pull: errore: Entry foo not uptodate. Impossibile unire

Question

Sto tentando di aggiornare il mio repository da un ramo remoto e continuo a ricevere questo errore quando eseguo un "git pull". Non ho apportato alcuna modifica locale, e anche se ho non ho bisogno di tenerli.

ho provato:

git azzerato --hard

e ottengo lo stesso problema

L'unica cosa che sembra funzionare è l'eliminazione del file incriminato e provare un git tirare di nuovo .

Ho anche provato "git stash" seguito da un "git pull". Non andare.

modifica: utilizzando PortableGit-1.6.4-preview20090729 in modo da correggere eventuali bug precedenti con errori spuri.

Answer 1

In generale, ciò significa che sono presenti modifiche nei file locali che non sono stati salvati nel repository locale. Puoi anche vedere questo stackoverflow question per ulteriori dettagli.

Answer 2

Vale la pena provare:

Potrebbe impostare, proprio per questo aggiornamento, impostare il config parameter core.trustctime false?

core.trustctime 

If false, the ctime differences between the index and the working copy are ignored; useful when the inode change time is regularly modified by something outside Git (file system crawlers and some backup systems).

Answer 3

Ci sono un paio di modi per risolvere questo, ma ho trovato git scorta funziona bene per me. Temporaneamente mette le tue modifiche locali in un altro posto. Quindi puoi tirare, per afferrare le ultime modifiche. E poi puoi ripristinare le tue modifiche locali.

Proprio come questo:

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

$ git stash 
$ git pull 
$ git stash pop 

Answer 4

Questo tipo di problema è spesso causato dal tentativo di estrarre da un repository che ha due nomi che differiscono solo in caso. Se sei su FAT, NTFS in modalità maiuscole/minuscole (essenzialmente, ogni volta che viene utilizzato in Windows), o HFS + in modalità maiuscole e minuscole, e hai due file "foobar" e "FOOBAR", Git vedrà due distinti file, ma il filesystem ne vedrà solo uno, che causerà tutti i tipi di problemi. Git effettuerà il checkout, per esempio "FOOBAR", e quindi eseguirà il checkout di "foobar", che il filesystem vede semplicemente sostituendo il contenuto di "FOOBAR" ma lasciandolo sul posto. Ora a Git, sembra che "FOOBAR" sia stato sostituito con il contenuto di "foobar", e "foobar" sia sparito.

Ci sono due diverse manifestazioni di questo problema di base. Uno è quando il repository contiene effettivamente due file che differiscono solo per caso. In questo caso, è necessario lavorare su un file system sensibile al maiuscolo/minuscolo, 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 non può semplicemente memorizzare il contenuto di questo repository.

Un caso diverso che è possibile aggirare è quando si verifica un cambio di nome che cambia il caso del file. Supponiamo, ad esempio, che il repository Git contenga un nome da "ESEMPIO" ad "esempio". Prima che Git controlli la nuova versione, cercherà di verificare che non sovrascriva alcun file esistente sul disco. Siccome 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 sarà sovrascritta file non tracciati. In questo caso, se non hai modifiche locali che ti interessano, un semplice git reset --hard <revision-to-checkout> sarà in genere sufficiente per superare il problema e la nuova revisione.Basta provare a ricordare di non rinominare i file con altri nomi che differiscono solo nel caso in cui si è in un file system senza distinzione tra maiuscole e minuscole, in quanto causerà problemi come questo.

Answer 5

Potrebbe verificarsi un problema anche con i permessi dei file. Git sta anche facendo il versioning, a meno che config non dica altrimenti. Basta aggiungere questa risposta per le persone che hanno quasi ma non il problema simile.

Answer 6

Per ulteriori dettagli sul post di @Brian Campbell (perché anche reset hard non ha funzionato) voglio sottolineare un caso limite che mi ha fermato.

Avevo spostato un file OldFile in un'altra cartella e l'ho rinominato NewFile. Ho quindi contrassegnato il file come assume-unchanged.

Questo mi ha impedito di cambiare ramo e non c'era alcuna scorta da salvare o impegnare a spingere. Il problema era che non ho commesso questo cambio di file con un nuovo nome prima di impostare il flag assume-unchanged. Quindi l'ho impostato su no-assume-unchanged, l'ho eseguito, quindi lo ho impostato su assume-unchanged e ho potuto cambiare di nuovo i rami.

Answer 7

Stavo vedendo un problema simile (Windows 10): ero su branchA e volevo andare a master. Ho avuto alcune modifiche non modificate, quindi prima I git stash quindi git checkout -f master ma ho ancora ottenuto il Entry 'fileName' not uptodate. Cannot merge.

git status non mostrava nulla da commettere.

Eventualmente ho appena rimosso il file manualmente e sono stato in grado di andare all'altro ramo (che ovviamente ha reso il mio file di ritorno) quindi immagino ci sia stato un bug all'interno di git da qualche parte.

Answer 8

Questo può accadere se si aggiorna l'indice di ignorare determinati file:

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

e poi per esempio cassa qualche altro ramo:

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

Forzare l'aggiornamento dell'indice di risolvere il problema:

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

Seguito da:

git reset --hard 

E quindi tutto dovrebbe tornare alla normalità.