¿Puede alguien explicarme qué diferencia está viendo git diff aquí?
⏰ 5 minutos de lectura
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:
Echa un vistazo a la rama maestra.
Echa un vistazo a la rama prístine-3.7.
Echa un vistazo a la rama prístina-3.8.
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.
Aquí está la salida de diferencia para el mismo archivo usando Beyond Compare en modo hexadecimal.
Y finalmente, ¡la salida de estado de git!
¿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
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.
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?
Tu feedback nos ayuda a saber si la solución es correcta y está funcionando. De esta manera podemos revisar y corregir el contenido.
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
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, elcore.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 unrm .git/index
seguido de ungit 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 ungit ls-tree HEAD
y ungit 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