¿Puede alguien explicarme qué diferencia está viendo git diff aquí?

5 minutos de lectura

avatar de usuario
Umar Farooq Khawaja

Estoy usando git en Windows 7 a través de msysgit. Un problema que me ha estado causando mucho dolor últimamente es que tan pronto como cambio a ciertas ramas, git piensa que algunos archivos han cambiado y luego no puedo hacer nada para que deje de pensar que esos archivos han cambiado.

Los pasos para reproducir en mi caso (que pueden no ser relevantes para todos) son los siguientes:

  1. Echa un vistazo a la rama maestra.
  2. Echa un vistazo a la rama prístine-3.7.
  3. Echa un vistazo a la rama prístina-3.8.
  4. Echa un vistazo a la rama prístina-3.9.

En este punto, git comienza a asumir que los archivos han cambiado.

Por ejemplo, aquí hay una captura de pantalla de una salida de git diff.

salida de diferencia de git

Aquí está la salida de diferencia para el mismo archivo usando Beyond Compare en modo hexadecimal.

ingrese la descripción de la imagen aquí

Y finalmente, ¡la salida de estado de git!

ingrese la descripción de la imagen aquí

¿Qué está sucediendo?

Actualización a la pregunta:

Una posible solución es confirmar los cambios localmente y luego eliminar esa confirmación. sin volver a poner los cambios en la confirmación en el estado de trabajo. ¿Cómo se hace eso?

  • Si no hay una diferencia funcional obvia, simplemente use git checkout -- filename.x para recuperar el “original” tal como está almacenado en el repositorio.

    – Mihai Stancu

    24 de abril de 2014 a las 11:05

  • Lo probé junto con otras correcciones sugeridas, como la core.autocrlf ajuste, el core.filemode configuración, etc., restablecimientos completos y reversiones. Lo único que lo arregla es enviar esos archivos. Eso es algo que no quiero hacer (porque quiero esas ramas congeladas). Revertir/restablecer no ayuda. he probado un rm .git/index seguido de un git reset --hard así como.

    – Umar Farooq Khawaja

    24 de abril de 2014 a las 11:08


  • Los bloques rojos que muestra git diff son espacios en blanco al final. Esto podría tener que ver con CRLF. No soy un experto en el tema, pero tal vez esto te pueda ayudar.

    – Tim

    24 de abril de 2014 a las 12:34

  • Ese fue mi pensamiento inicial también. Es por eso que realicé la comparación hexadecimal (la captura de pantalla del medio). La comparación hexadecimal no muestra ni un solo byte diferente entre los 2 archivos.

    – Umar Farooq Khawaja

    24 de abril de 2014 a las 13:22


  • utilizar git checkout filename para recuperar el archivo antiguo antes de los “cambios”. ¿Has comprobado los permisos del archivo? hacer un git ls-tree HEAD y un git ls-tree abc1234 y comparar (abc1234 debe reemplazarse con el HEX de la confirmación anterior)

    –Michael Tomkins

    4 de mayo de 2014 a las 11:04

avatar de usuario
Sr_y_Sra_D

Tengo este problema constantemente, lo único que funciona es:

git rm --cached -r . > /dev/null # redirect if output is huge
git reset --hard

pero asegúrese de que no tiene cambios que desee conservar

Ver finales de línea de git: no se puede esconder, restablecer y ahora no se puede volver a establecer la base sobre la confirmación de finales de línea espurios

Alguien debe hacer un repositorio de ejemplo que muestre este comportamiento y publicarlo en el rastreador de git; esto es un error (en el sentido de que git reset --hard y compañía deberían funcionar de inmediato)

EDITAR: asegúrese de haber leído el lectura obligatoria y configurar un .gitattributes expediente

  • Gracias por agregar una respuesta, aunque después de meses de dolor y algo de trabajo perdido, salté a Mercurial, que creo que es mejor de todos modos, pero esto podría ser útil para otros menos afortunados que yo 🙂

    – Umar Farooq Khawaja

    14 de julio de 2014 a las 9:52

  • @UmarFarooqKhawaja: Debería estar en desacuerdo contigo aquí, git es tan increíble, pero sí, encontrarás algunos inconvenientes, este es probablemente el que no entiendo completamente. Pero uno debería tratar de producir un ejemplo reproducible y publicar un error en lugar de huir. Git tiene características que Mercurial simplemente no tiene, así que una buena mañana lo extrañarás 🙂

    – Sr_y_Sra_D

    14 de julio de 2014 a las 12:47

  • Por lo que puedo decir, es Git el que carece de funciones, no Mercurial. ¿Qué características tienes en mente?

    – Umar Farooq Khawaja

    14 de julio de 2014 a las 13:04

  • @UmarFarooqKhawaja: ¿mercurial puede rastrear el movimiento de una función de un archivo a otro? ¿Puedes reorganizar interactivamente tu sucursal? Diablos, escuché que ni siquiera tiene un índice: D

    – Sr_y_Sra_D

    14 de julio de 2014 a las 13:24

Suena como autocrlf asunto. Además, es posible que tenga smudge y clean filtros habilitados con una implementación personalizada que está causando problemas.

Sugiero hacer

git diff --raw master pristine-3.9 -- packages/fop-10/lib
git diff --raw pristine-3.7 pristine-3.9 -- packages/fop-10/lib

e inspeccionando los resultados. El resto aseguró que git guarda el contenido binario y el contenido binario guardado coincide con el SHA-1 de la punta de la rama. Sin embargo, los contenidos binarios pueden no coincidir con el directorio de trabajo contenidos binarios si utiliza algunas características (por ejemplo, autocrlf o smudge). los autocrlf es más propenso a causar problemas a los usuarios de Windows porque los usuarios de Windows todavía sufren de una decisión histórica de Microsoft de usar un código de dos bytes para un solo avance de línea en lugar de un código de un solo byte usado en los sistemas históricos compatibles con UNIX y el sistema operativo Machintosh.

¿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