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

Question

Estoy tratando de actualizar mi repositorio desde una sucursal remota y sigo recibiendo este error cuando hago un "git pull". No hice ningún cambio local, y aunque lo tenga, no es necesario que los guarde.

He intentado:

git reset --hard

y consigo el mismo problema

Lo único que parece funcionar es borrar el archivo infractor y probar un nuevo git pull .

También probé "git stash" seguido de "git pull". No vayas.

editar: utilizando PortableGit-1.6.4-preview20090729 por lo que cualquier error anterior con errores espurios debe ser reparado.

Answer 1

En general, esto significa que tiene cambios en sus archivos locales que no han sido enviados a su repositorio local. También puede ver este stackoverflow question para un poco más de detalle.

Answer 2

Vale la pena probarlo:

pudo establecer que, sólo por esta actualización, establezca la config parameter core.trustctime a falso?

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

Hay un par de maneras de solucionar esto, pero he encontrado escondite Git funciona bien para mí. Es temporal coloca tus cambios locales en otro lugar. Luego puede tirar, para agarrar los últimos cambios. Y luego puede recuperar sus cambios locales.

Al igual que este:

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

$ git stash 
$ git pull 
$ git stash pop 

Answer 4

Este tipo de problema es causada frecuentemente por tratar de tirar de un repositorio que tiene dos nombres de archivo que se diferencian sólo en el caso. Si está en FAT, NTFS en modo insensible a mayúsculas y minúsculas (esencialmente, cada vez que se usa en Windows) o HFS + en modo insensible a mayúsculas y minúsculas y tiene dos archivos "foobar" y "FOOBAR", entonces Git verá dos archivos, pero el sistema de archivos solo verá uno, lo que causará todo tipo de problemas. Git registrará, digamos, "FOOBAR", y luego presiona "foobar", que el sistema de archivos ve como simplemente reemplazar los contenidos de "FOOBAR" pero dejándolo en su lugar. Ahora, para Git, parece que "FOOBAR" ha sido reemplazado por el contenido de "foobar", y "foobar" se ha ido.

Existen dos manifestaciones diferentes de este problema básico. Una es cuando su repositorio en realidad contiene dos archivos que difieren solo en el caso. En este caso, debe trabajar en un sistema de archivos con distinción 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 insensible a 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 "EJEMPLO" a "ejemplo". Antes de que Git revise la nueva versión, intentará verificar que no sobrescriba algún archivo existente que tenga en su disco. Como cree que "ejemplo" es un nuevo nombre de archivo, 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 simple git reset --hard <revision-to-checkout> generalmente será suficiente para superar el problema y la nueva revisión.Intente y recuerde no cambiar el nombre de los archivos a otros nombres que difieran solo en caso de que esté en un sistema de archivos que no distingue entre mayúsculas y minúsculas, ya que esto provocará problemas como este.

Answer 5

Podría ser un problema también con los permisos de archivos. Git también los está versionando, a menos que config indique lo contrario. Solo agregue esta respuesta para las personas que tienen casi un problema similar.

Answer 6

Para profundizar en la publicación de @Brian Campbell (porque el reinicio no funcionó tampoco), quiero señalar una caja de borde que me estaba deteniendo.

He movido un archivo OldFile a una carpeta diferente y lo he cambiado NewFile. Luego marqué el archivo como assume-unchanged.

Esto me impedía cambiar de rama y no había ningún escondite para guardar o comprometerme a presionar. El problema fue que no cometí este cambio de archivo con un nuevo nombre antes de configurar el indicador assume-unchanged. Así que lo configuré de nuevo en no-assume-unchanged, lo comprometí, luego lo configuré de nuevo en assume-unchanged y pude cambiar de nuevo sucursales.

Answer 7

Estaba viendo un problema similar (Windows 10): estaba en branchA y quería ir al master. Tuve algunos cambios sin compromiso así que primero I git stash luego git checkout -f master pero todavía tengo el Entry 'fileName' not uptodate. Cannot merge.

git status no mostró nada para confirmar.

Eventualmente acabo de eliminar el archivo manualmente y pude ir a la otra rama (que por supuesto hizo que mi archivo vuelva) así que supongo que ha habido un error dentro de git en alguna parte.

Answer 8

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

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

y luego, por ejemplo, la caja otra rama:

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

Forzar actualización de índice corrige el problema:

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

Seguido por:

git reset --hard 

Y todo debería volver a la normalidad.