Git pull: error: Entrada foo no actualizada. No se puede fusionar

86

Estoy tratando de actualizar mi repositorio desde una rama remota y sigo recibiendo este error cuando hago un "git pull". No he realizado ningún cambio local, e incluso si lo hice, no necesito mantenerlos.

He intentado:

git reset --hard

y me sale el mismo problema

Lo único que parece funcionar es eliminar el archivo ofensivo e intentar un git pull nuevamente.

También lo intenté git stashseguido de un git pull. No vayas.

editar: usando PortableGit-1.6.4-preview20090729, por lo que cualquier error anterior con errores falsos debe corregirse.

git

— yuit
fuente

Vea si la explicación en git.or.cz/gitwiki/GitFaq ayuda.

— Jakub Narębski

Lo mismo ocurre con " Lo único que parece funcionar es eliminar el archivo ofensivo y volver a intentar un git pull ". Para mí, al menos un archivo no estaba en git; fue .gitignored por una regla comodín. Sin embargo, no estoy seguro de por qué eran bloqueadores.

— ruffin

3

Pude resolver esto ejecutando git rm --cached learned/tests/temp_funcs.py: como de todos modos quería que el archivo permaneciera en la lista de Archivos sin seguimiento , git rm --cachedme desbloqueé en este caso.

— Deep

1

Esto me sucedió durante una fusión que deseaba --abort. Ninguna de las soluciones propuestas me permitió abortar, excepto eliminar los archivos ofensivos.

— Trevor Reid

55

Hay un par de formas de solucionar este problema, pero he descubierto que git stash funciona bien para mí. Coloca temporalmente los cambios locales en otro lugar. Luego, puede tirar para obtener los últimos cambios. Y luego puede recuperar sus cambios locales.

Así:

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

$ git stash
$ git pull
$ git stash pop

— manat
fuente

21

De la pregunta original: "También probé" git stash "seguido de un" git pull ". No, vaya".

— Charles Wood

No funcionó para mí, en mi caso tuve que hacerlo git rm --cached, comentario completo: stackoverflow.com/questions/1248029/…

— Deep

37

Esto puede suceder si actualiza el índice para ignorar ciertos archivos:

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

y luego, por ejemplo, verifique alguna otra rama:

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

Forzar la actualización del índice soluciona el problema:

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

Seguido por:

git reset --hard

Y luego todo debería volver a la normalidad.

— hábitats
fuente

1

Pude resolver esto ejecutando git rm --cached learned/tests/temp_funcs.py: como de todos modos quería que el archivo permaneciera en la lista de Archivos sin seguimiento , git rm --cachedme desbloqueé en este caso.

— Deep

3

¡ git update-index --really-refreshEra la pieza que faltaba! Bien hecho, esto fue difícil de encontrar

— Bernardo Dal Corno

28

Este tipo de problema se produce con frecuencia al intentar extraer de un repositorio que tiene dos nombres de archivo que solo difieren en el caso. Si está en FAT, NTFS en modo que no distingue entre mayúsculas y minúsculas (esencialmente, cada vez que se usa en Windows) o HFS + en modo que no distingue entre mayúsculas y minúsculas, y tiene dos archivos "foobar" y "FOOBAR", Git verá dos archivos distintos archivos, pero el sistema de archivos solo verá uno, lo que causará todo tipo de problemas. Git comprobará, digamos, "FOOBAR", y luego comprobará "foobar", que el sistema de archivos ve como simplemente reemplazar el contenido de "FOOBAR" pero dejándolo en su lugar. Ahora para Git, parece que "FOOBAR" ha sido reemplazado con el contenido de "foobar", y "foobar" ha desaparecido.

Hay dos manifestaciones diferentes de este problema básico. Uno es cuando su repositorio realmente contiene dos archivos que difieren solo en el caso. En este caso, debe trabajar en un sistema de archivos que distinga entre mayúsculas y minúsculas, o deberá editar el repositorio para asegurarse de que no se produzcan colisiones de este tipo; un sistema de archivos que no distingue entre mayúsculas y minúsculas simplemente no puede almacenar el contenido de este repositorio.

Un caso diferente que puede solucionar es cuando ocurre un cambio de nombre que cambia el caso del archivo. Digamos, por ejemplo, que el repositorio de Git contiene un cambio de nombre de "EXAMPLE" a "example". Antes de que Git verifique la nueva versión, intentará verificar que no esté sobrescribiendo algún archivo existente que tenga en su disco. Como piensa que "ejemplo" es un nuevo nombre de archivo, le preguntará al sistema de archivos si existe, y el sistema de archivos verá "EJEMPLO" y dirá que sí, por lo que Git se negará a verificar la nueva versión ya que cree que se sobrescribirá. archivos sin seguimiento. En este caso, si no tiene cambios locales que le interesen, un simplegit reset --hard <revision-to-checkout>generalmente será suficiente para superar el problema y realizar la nueva revisión. Solo intente y recuerde no cambiar el nombre de los archivos a otros nombres que difieran solo en el caso de que esté en un sistema de archivos que no distingue entre mayúsculas y minúsculas, ya que causará problemas como este.

— Brian Campbell
fuente

14

Para obtener más detalles sobre la publicación de @Brian Campbell (porque el restablecimiento completo tampoco funcionó), quiero señalar un caso límite que me estaba deteniendo.

Había movido un archivo OldFilea una carpeta diferente y le había cambiado el nombre NewFile. Luego marqué el archivo como assume-unchanged.

Esto me impedía cambiar de rama y no había ningún alijo que guardar o comprometerme a empujar. El problema fue que no cometí este cambio de archivo con un nuevo nombre antes de configurar la assume-unchangedbandera. Así que lo puse de nuevo en no-assume-unchanged, lo comprometí, luego lo assume-unchangedpuse de nuevo en y pude cambiar de rama nuevamente.

— Agresor
fuente

1

Esta respuesta me puso en el camino correcto, gracias. Usé "git ls-files -v | grep '^ [[: lower:]]' | awk '{print $ 2}' | xargs git update-index --no-ass-unchanged" para restablecer el indicador de asumir sin cambios , luego pude restablecer - hard sin errores.

— ocroquette

Creo que esto también se aplica a cualquier archivo marcado como 'asumir sin cambios', tuve el mismo problema al ignorar los cambios en un archivo local que tenía su nombre original. Tu comentario me recordó que había marcado ese archivo, ¡gracias!

— Jake_

5

Tengo el mismo problema. Básicamente, "asumir sin cambios" es una característica maligna. Una vez que lo usa, es MUY difícil verificar otras ramas. Incluso si lo usa checkout -f, fallará.

— John Henckel

13

En términos generales, esto significa que tiene cambios en sus archivos locales que no se han confirmado en su repositorio local. También puede ver esta pregunta sobre el flujo de pila para obtener más detalles.

— codigo encarnado
fuente

11

De la pregunta: "No he realizado ningún cambio local ..."

— Charles Wood

Es un error de git o es una corrupción del repositorio de git.

— Warren P

11

Estaba viendo un problema similar (Windows 10): estaba encendido branchAy quería ir a master. Tuve algunos cambios no comprometidos, así que primero yo git stashluego, git checkout -f masterpero todavía tengo el Entry 'fileName' not uptodate. Cannot merge.

git status no mostraba nada que comprometer.

Finalmente, eliminé el archivo manualmente y pude ir a la otra rama (lo que, por supuesto, hizo que mi archivo volviera), así que supongo que ha habido un error dentro de git en alguna parte.

— usuario276648
fuente

1

Esta es la única solución a esta pregunta que me funcionó. ¡Recibía el error con el .gitignorearchivo! Aunque no le había hecho ningún cambio, y git no me permitía "esconderlo" (¡porque no hay cambios locales, duh!). Así que moví el .gitignorearchivo fuera del repositorio (como una especie de "copia de seguridad") y luego hice una git reset --hard, que "arregló" el repositorio en un estado sano.

— Hombre enmascarado

git statusme mostró qué archivo se cambió e insinuó que podía usarlo en git restore myFilelugar de eliminarlo, lo que funcionó.

— Noumenon

7

También podría ser un problema con los permisos de archivos. Git también los está versionando, a menos que config diga lo contrario. Solo agrego esta respuesta para personas que tienen casi, pero no un problema similar.

— Drachenfels
fuente

5

Vale la pena intentarlo:

¿Podría establecer, solo para esta actualización, establecer el parámetro de configuracióncore.trustctime en falso?

core.trustctime

Si es falso, se ignoran las diferencias de ctime entre el índice y la copia de trabajo; útil cuando el tiempo de cambio de inodo es modificado regularmente por algo externo a Git (rastreadores del sistema de archivos y algunos sistemas de respaldo).

— VonC
fuente

2

Buen hallazgo, esto realmente funcionó para mí cuando vi el mensaje de error anterior al ejecutar "git reset --merge". Cuando configuré este parámetro en falso, se deshizo del error.

— DemitryT

1

Funcionó para mí al verificar si había conflictos con otra rama usando "git merge <feature> --no-ff --no-commit" y luego volviendo con "git merge --abort". Xcode era "algo fuera de Git" en este caso. ¡Gracias casi 10 años después!

— Ralfonso

@Ralfonso Casi diez años después, de

— nada

2

Agregando mi respuesta porque ninguno de los demás menciona esto. En mi caso, esto sucedió después de que agregué nuevos archivos al índice con la -Nbandera, así que simplemente los agregué al índice sin agregar su contenido. En este estado, hacer git stashproduce este error.

— Aviad P.
fuente

0

Tuve el mismo error, después de una situación en la que se git statusdecía new file: foo.cppque no se agregó un archivo al área de preparación. es decir, bajo el título "Cambios no preparados para confirmar". Muy extraño, esto generalmente no sucede.

Solución: git add foo.cppy luego git stashfuncionó de nuevo.

— David Faure
fuente