El estado de Git muestra los archivos como cambiados aunque el contenido sea el mismo

12 minutos de lectura

El estado de Git muestra los archivos como cambiados aunque
Aron Rotteveel

Recibí un git checkout de otra persona y estoy tratando de confirmar los cambios no preparados en el repositorio local. Sin embargo, un lote (si no todos) el archivo aparece como modificado aunque el contenido sea exactamente el mismo.

ya me puse core.fileMode a falso y también establecer core.autocrlf a falso, sin éxito.

Vale la pena mencionar que el repositorio de Git que recibí fue de alguien que usa Windows, mientras que yo uso Linux.

¿Qué puedo hacer para cometer el real ¿cambios?

EDITAR: salida de git config -l:

user.name=Aron Rotteveel
user.email=<removed>
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.ui=true
color.pager=true
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
core.pager=less -FRSX
core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
alias.co=checkout
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=false
remote.origin.url=<removed>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

Actualización: se agregaron algunos archivos de ejemplo aleatorios. Estos archivos son solo texto sin formato, por lo que son los más fáciles de incluir.

Los archivos originales se encuentran aquí: https://gist.github.com/c3c5302430935155ef3d. Hexdumps definitivamente indican que los archivos son diferentes, pero no tengo idea de qué causa esto y cómo solucionarlo.

Versión CABEZA:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740d  HTML.SafeObject.
0000010: 0a54 5950 453a 2062 6f6f 6c0d 0a56 4552  .TYPE: bool..VER
0000020: 5349 4f4e 3a20 332e 312e 310d 0a44 4546  SION: 3.1.1..DEF
0000030: 4155 4c54 3a20 6661 6c73 650d 0a2d 2d44  AULT: false..--D
0000040: 4553 4352 4950 5449 4f4e 2d2d 0d0a 3c70  ESCRIPTION--..<p
0000050: 3e0d 0a20 2020 2057 6865 7468 6572 206f  >..    Whether o
0000060: 7220 6e6f 7420 746f 2070 6572 6d69 7420  r not to permit 
0000070: 6f62 6a65 6374 2074 6167 7320 696e 2064  object tags in d
0000080: 6f63 756d 656e 7473 2c20 7769 7468 2061  ocuments, with a
0000090: 206e 756d 6265 7220 6f66 2065 7874 7261   number of extra
00000a0: 0d0a 2020 2020 7365 6375 7269 7479 2066  ..    security f
00000b0: 6561 7475 7265 7320 6164 6465 6420 746f  eatures added to
00000c0: 2070 7265 7665 6e74 2073 6372 6970 7420   prevent script 
00000d0: 6578 6563 7574 696f 6e2e 2054 6869 7320  execution. This 
00000e0: 6973 2073 696d 696c 6172 2074 6f0d 0a20  is similar to.. 
00000f0: 2020 2077 6861 7420 7765 6273 6974 6573     what websites
0000100: 206c 696b 6520 4d79 5370 6163 6520 646f   like MySpace do
0000110: 2074 6f20 6f62 6a65 6374 2074 6167 732e   to object tags.
0000120: 2020 596f 7520 7368 6f75 6c64 2061 6c73    You should als
0000130: 6f20 656e 6162 6c65 0d0a 2020 2020 254f  o enable..    %O
0000140: 7574 7075 742e 466c 6173 6843 6f6d 7061  utput.FlashCompa
0000150: 7420 696e 206f 7264 6572 2074 6f20 6765  t in order to ge
0000160: 6e65 7261 7465 2049 6e74 6572 6e65 7420  nerate Internet 
0000170: 4578 706c 6f72 6572 0d0a 2020 2020 636f  Explorer..    co
0000180: 6d70 6174 6962 696c 6974 7920 636f 6465  mpatibility code
0000190: 2066 6f72 2079 6f75 7220 6f62 6a65 6374   for your object
00001a0: 2074 6167 732e 0d0a 3c2f 703e 0d0a 2d2d   tags...</p>..--
00001b0: 2320 7669 6d3a 2065 7420 7377 3d34 2073  # vim: et sw=4 s
00001c0: 7473 3d34 0d0a                           ts=4..

Versión copiada:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740a  HTML.SafeObject.
0000010: 5459 5045 3a20 626f 6f6c 0a56 4552 5349  TYPE: bool.VERSI
0000020: 4f4e 3a20 332e 312e 310a 4445 4641 554c  ON: 3.1.1.DEFAUL
0000030: 543a 2066 616c 7365 0a2d 2d44 4553 4352  T: false.--DESCR
0000040: 4950 5449 4f4e 2d2d 0a3c 703e 0a20 2020  IPTION--.<p>.   
0000050: 2057 6865 7468 6572 206f 7220 6e6f 7420   Whether or not 
0000060: 746f 2070 6572 6d69 7420 6f62 6a65 6374  to permit object
0000070: 2074 6167 7320 696e 2064 6f63 756d 656e   tags in documen
0000080: 7473 2c20 7769 7468 2061 206e 756d 6265  ts, with a numbe
0000090: 7220 6f66 2065 7874 7261 0a20 2020 2073  r of extra.    s
00000a0: 6563 7572 6974 7920 6665 6174 7572 6573  ecurity features
00000b0: 2061 6464 6564 2074 6f20 7072 6576 656e   added to preven
00000c0: 7420 7363 7269 7074 2065 7865 6375 7469  t script executi
00000d0: 6f6e 2e20 5468 6973 2069 7320 7369 6d69  on. This is simi
00000e0: 6c61 7220 746f 0a20 2020 2077 6861 7420  lar to.    what 
00000f0: 7765 6273 6974 6573 206c 696b 6520 4d79  websites like My
0000100: 5370 6163 6520 646f 2074 6f20 6f62 6a65  Space do to obje
0000110: 6374 2074 6167 732e 2020 596f 7520 7368  ct tags.  You sh
0000120: 6f75 6c64 2061 6c73 6f20 656e 6162 6c65  ould also enable
0000130: 0a20 2020 2025 4f75 7470 7574 2e46 6c61  .    %Output.Fla
0000140: 7368 436f 6d70 6174 2069 6e20 6f72 6465  shCompat in orde
0000150: 7220 746f 2067 656e 6572 6174 6520 496e  r to generate In
0000160: 7465 726e 6574 2045 7870 6c6f 7265 720a  ternet Explorer.
0000170: 2020 2020 636f 6d70 6174 6962 696c 6974      compatibilit
0000180: 7920 636f 6465 2066 6f72 2079 6f75 7220  y code for your 
0000190: 6f62 6a65 6374 2074 6167 732e 0a3c 2f70  object tags..</p
00001a0: 3e0a 2d2d 2320 7669 6d3a 2065 7420 7377  >.--# vim: et sw
00001b0: 3d34 2073 7473 3d34 0a                   =4 sts=4.

  • Si usted tiene core.filemode desarmar, o poner a true¿la salida es diferente?

    –Mark Longair

    26 de abril de 2011 a las 9:20

  • La otra información importante que ayudaría es la salida de git --version

    –Mark Longair

    26 de abril de 2011 a las 11:10

  • @AronRotteveel: Eso es fácil: el primer archivo tiene finales de línea CRLF (Windows), el segundo LF (Unix)

    – seje

    23 de noviembre de 2011 a las 14:36

  • git 2.8 (marzo de 2016) presenta git ls-files --eol, para ver rápidamente si EOL está involucrado. Mira mi respuesta a continuación

    – VoC

    4 de febrero de 2016 a las 15:03


  • La persona en Windows puede ejecutar git config –global core.autocrlf verdadero para resolver este problema.

    – Inyoka

    21 de marzo de 2018 a las 7:02

Unstaged changes left after git reset hard
Jacek Szybisz

He resuelto este problema usando los siguientes pasos

  1. Elimina todos los archivos del índice de Git.

    git rm --cached -r .

  2. Vuelva a escribir el índice de Git para recoger todos los finales de línea nuevos.

    git reset --hard

Tenga en cuenta que el paso 2 puede eliminar sus cambios locales. La solución fue parte de los pasos descritos en el sitio de git
https://help.github.com/articles/dealing-with-line-endings/

  • En mi caso, hice un montón de notas en algunos archivos y luego copié el repositorio sin la carpeta .git en una computadora nueva. Cuando me di cuenta de que me faltaba mi paquete .git, era demasiado tarde para regresar y recuperarlo. Así que yo: 1. Revisé una nueva copia de todo el repositorio 2. Reemplacé los archivos de vainilla con los archivos con mis cambios 3. Ejecuté el paso uno en la publicación del OP: git rm --cached -r . 4. Esto preparó mis cambios (y cualquier otro archivo que se reemplazó), así que los quité. En este punto, mi repositorio volvió a la normalidad.

    – cody

    27 de agosto de 2018 a las 18:26


  • Brillante. Gracias por esto.

    – Herbert

    1 de febrero de 2019 a las 12:08

  • Debe tener cuidado ya que perderá cualquier otro cambio si lo hace.

    – Mohy Eldeen

    6 mayo 2019 a las 19:00

  • Tuve este problema después de copiar y pegar mi carpeta de repositorio de Windows a Ubuntu. No hubo cambios locales, pero por alguna razón, git pensó que todos los archivos habían cambiado. Esta solución resolvió este problema.

    – Líneak

    6 dic 2019 a las 11:00

  • Una excelente solución para quienes usan Windows, pero trasladan su entorno de desarrollo a Linux o WSL (que es como llegué aquí).

    – Josué Schlichting

    23 de julio de 2020 a las 15:21

El estado de Git muestra los archivos como cambiados aunque
esandy

¿Ha cambiado el modo de los archivos? Lo hice en mi máquina y la máquina de desarrollo local tenía 777 asignados a todos los archivos, mientras que el repositorio tenía 755 que mostraba todos los archivos modificados. yo hice git diff y mostró que el modo antiguo y el modo nuevo son diferentes. Si ese es el problema, puede ignorarlos fácilmente
git config core.filemode false

Salud

  • Usando Windows 10 lxss (es decir, Ubuntu Bash) con un repositorio en el sistema de archivos de Windows con git en Linux, pensé que era un problema de final de línea. Ni siquiera había considerado que podría haber sido la forma en que los modos de archivo también son diferentes.

    – Matt L.

    2 de marzo de 2018 a las 17:25

  • Esto funcionó para mí cuando cambié mi sistema operativo local de Ubuntu a Windows. Salud

    – Mark Buckell

    26 de abril de 2018 a las 2:59

  • @MattL y itsandy Usualmente desarrollo en Win 10 con Git Bash, pero hoy estoy en Mac y veo que git piensa .gitignore los archivos han cambiado cuando no lo han hecho. En esta Mac, git config core.filemode responde con true. lo cambié a falsepero eso no ayudó.

    – Ryan

    30 de diciembre de 2018 a las 15:19

  • tu eres el verdadero dios

    – gursahib.singh.sahni

    22 de enero de 2021 a las 19:03

  • Por qué core.filemode está habilitado por defecto? Esto probablemente arruinó muchos historiales de repositorios limpios.

    – Martín Braun

    28 de mayo de 2021 a las 4:38

1646751258 679 El estado de Git muestra los archivos como cambiados aunque
seje

Actualización: según el comentario sobre esta pregunta, el problema se ha resuelto:

Eso es fácil: el primer archivo tiene finales de línea CRLF (ventanas), el segundo LF (Unix). los file util (disponible en git\usr\bin) le mostrará que (file a b responderá algo como a: ASCII text, with CRLF line terminators b: ASCII
text
)

Respuesta original a continuación:


La diferencia que muestras no no mostrar una sola línea diferente. ¿Puedes publicar .git/config (o mejor git config -l).

Es posible que tenga algunos espacios en blanco ignorados activados

Deberías intentar deshabilitar core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

además

git show HEAD:myfile|md5sum
md5sum myfile

podría usarse para verificar que los archivos son de hecho diferentes. Usar diff externo también podría funcionar

git show HEAD:myfile > /tmp/myfile.HEAD

diff -u myfile /tmp/myfile.HEAD

# or if you prefer an interactive tool like e.g.:
vim -d myfile /tmp/myfile.HEAD

  • Lo extraño es que los md5sums para ambos archivos son diferentes pero no puedo encontrar NINGUNA diferencia de espacios en blanco. (Supongo que este es el caso, pero simplemente no lo veo). Cualquier ayuda sera bienvenida.

    – Aron Rotteveel

    23 de noviembre de 2011 a las 14:12

  • Simplemente cargue un ejemplo en algún lugar (gist.github.com sería apropiado para esto). Supongo que es con nueva línea en la última línea, un marca de orden de bytes, o codificaciones UTF8 no canónicas en general. Siempre puedes mirar xxd o bdiff hacer diferencias binarias también

    – seje

    23 de noviembre de 2011 a las 14:14


  • gracias por el consejo. xdd era nuevo para mi ¡Gran herramienta! Actualicé mi publicación con un ejemplo.

    – Aron Rotteveel

    23 de noviembre de 2011 a las 14:27

  • @AronRotteveel: Eso es fácil: el primer archivo tiene finales de línea CRLF (ventanas), el segundo LF (Unix). Editar los file util le mostrará que (file a b responderá algo como a: ASCII text, with CRLF line terminators b: ASCII text)

    – seje

    23 de noviembre de 2011 a las 14:41

  • Soy mi caso, el hash es el mismo, pero git aún indica un cambio

    – tofutim

    26 de junio de 2015 a las 20:31

1646751258 782 El estado de Git muestra los archivos como cambiados aunque
Población

Yo tuve el mismo problema. Después de win->lin copy tengo todos los archivos modificados. solía desdedos para arreglar los finales de línea y luego

git add -uv 

para agregar cambios. Agregó 3 archivos (no todos), que en realidad modifiqué. Después estado de Git muestra solo 3 archivos modificados. Después git cometer todo está bien con estado de Git.

En mi caso los archivos aparecían como modificados después cambiar los permisos de los archivos.

Para hacer que git ignore los cambios de permisos, haga lo siguiente:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

  • Tu respuesta me ahorró mucho tiempo. ¡Gracias!

    – Pavel_K

    23 de febrero de 2019 a las 15:12

  • Después de hacer esto, recomiendo esconder/escenificar el deseado cambios, restablecer/desproteger los archivos cuyos permisos han cambiado y luego volver a habilitar core.filemode. 🙂

    – XtraSimplicidad

    22 abr 2019 a las 21:45


  • Tuve este problema después de copiar los archivos de una computadora portátil a otra. Tu fijo lo guardó. ¡Gracias!

    – sam

    19 de junio de 2019 a las 19:43

1646751259 415 El estado de Git muestra los archivos como cambiados aunque
Comunidad

Pude solucionar los problemas en la máquina con Windows cambiando core.autocrlf de false a core.autocrlf=input

git config core.autocrlf input

como se sugiere en https://stackoverflow.com/a/1112313/52277

  • Tu respuesta me ahorró mucho tiempo. ¡Gracias!

    – Pavel_K

    23 de febrero de 2019 a las 15:12

  • Después de hacer esto, recomiendo esconder/escenificar el deseado cambios, restablecer/desproteger los archivos cuyos permisos han cambiado y luego volver a habilitar core.filemode. 🙂

    – XtraSimplicidad

    22 abr 2019 a las 21:45


  • Tuve este problema después de copiar los archivos de una computadora portátil a otra. Tu fijo lo guardó. ¡Gracias!

    – sam

    19 de junio de 2019 a las 19:43

Sin embargo, muchos archivos (si no todos) aparecen como modificados aunque el contenido sea exactamente el mismo.

Con Git 2.8 (marzo de 2016), podrá verificar rápidamente si esos cambios están relacionados con el final del ciclo de vida.

Si ese es el caso, Devin G Rhode agrega en los comentarios:

Resolví esto nuevamente agregando un .gitattributes archivo a un repositorio con solo * text=auto dentro de eso

Para el control, consulte cometer a7630bd (16 de enero de 2016) por Torsten Bögershausen (tboegi).
(Combinado por Junio ​​C Hamano — gitster en cometer 05f153903 de febrero de 2016)

ls-files: agregar diagnósticos de eol

Al trabajar en un entorno multiplataforma, es posible que un usuario desee verificar si los archivos de texto se almacenan normalizados en el repositorio y si .gitattributes se configuran adecuadamente.

Permita que Git muestre los finales de línea en el índice y en el árbol de trabajo y los atributos text/eol efectivos.

El final de la línea (“eolinfo“) se muestran así:

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

El atributo text/eol efectivo es uno de estos:

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

git ls-files --eol da una salida como esta:

i/none   w/none   attr/text=auto      t/t5100/empty
i/-text  w/-text  attr/-text          t/test-binary-2.png
i/lf     w/lf     attr/text eol=lf    t/t5100/rfc2047-info-0007
i/lf     w/crlf   attr/text eol=crlf  doit.bat
i/mixed  w/mixed  attr/               locale/XX.po

para mostrar qué convención de eol se usa en los datos del índice (‘i‘), en el árbol de trabajo (‘w‘), y qué atributo está en vigor, para cada ruta que se muestra.

  • Aunque esto muestra el problema, no lo soluciona.

    – Greso

    11 de febrero de 2020 a las 21:56

  • Esto proporcionó la mejor pista en mi situación. Tenía un archivo gradlew.bat que se modificó, y no importaba lo que hiciera para restablecer el directorio de trabajo (git reset –hard && git status y git reset –hard && rm gradlew.bat && git status && git checkout . && git status) el archivo quedó modificado. Tengo un .gitattributes global desde aquí: github.com/alexkaratarakis/gitattributes/blob/master/… con algunos bits extra de aquí: rehansaeed.com/gitattributes-best-practices

    – Devin Rhode

    2 sep 2020 a las 15:55

  • @DevinGRhode ¡Bien hecho! ls-files --eol es realmente útil.

    – VoC

    2 de septiembre de 2020 a las 16:12

  • Resolví esto nuevamente agregando un archivo .gitattributes a un repositorio con solo * text=auto dentro de él 🙂 – ¿tal vez poner esto en la parte superior de su respuesta?

    – Devin Rhode

    3 de octubre de 2020 a las 2:14


  • @DevinGRhode Gracias. He incluido tu comentario en la respuesta para mayor visibilidad.

    – VoC

    3 de octubre de 2020 a las 5:17

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad