¿Por qué git trata este file de text como binary y no proporciona una diferencia significativa?

Hacer una introducción al curso de git en Pluralsight y git no está cooperando con la sección de diferencias.

El sistema operativo es Windows 8.1. Intento diferir dos versiones de un file de text sin caracteres especiales. Creé este file de text en PowerShell a través de:

echo "Hello, world" > readme.txt 

El command regular diff dice que los files binarys son diferentes.

 PS C:\GitTest> git diff HEAD~1..HEAD diff --git a/readme.txt b/readme.txt index 440580d..0d6852b 100644 Binary files a/readme.txt and b/readme.txt differ 

Cuando lo forzo con –text obtengo esta salida:

 PS C:\GitTest> git diff --text HEAD~1..HEAD diff --git a/readme.txt b/readme.txt index 83f0e87..fef1216 100644 --- a/readme.txt +++ b/readme.txt @@ -1,2 +1,3 @@ -ÿþH-\ No newline at end of file +ÿþH++\ No newline at end of file 

No estoy seguro de por qué cree que es binary en primer lugar o por qué la diferencia anterior parece inútil. Las dos versiones del file se ven así:

CABEZA ~ 1:

 Hello, Git! Hello, again! Hello, for the last time! 

CABEZA:

 Hello, Git! Hello, again! Hello, for the last time! Hello, again I hope this really is the last time... 

Mi editor está usando CRLF, pero tengo git configurado en core.autocrlf = true. Me he asegurado de que las versiones HEAD y HEAD ~ 1 tengan una nueva línea al final del file.

enter image description here

Siento que probablemente me esté perdiendo algo simple. ¿Qué es eso? Cualquier ayuda es muy apreciada.

Esos primeros 2 caracteres en la diferencia (la y con puntos en ella y la espina) son la interpretación Latin-1 de los bytes 0xFF y 0xFE . Si esos bytes se interpretaran como UCS2 / UTF16, serían una marca de order de byte poco endian. Después de esos bytes, tiene la H de "Hello, world" y luego probablemente un NUL, lo que hace que el diff del modo de text forzado se rinda.

Por lo tanto, su editor de text ha guardado el file en formatting UTF16LE, que es bastante común en Windows pero raro en el mundo de Unix, de donde viene git. Es por eso que git está confundido.

Si puede decirle a su editor que guarde el file como UTF8 (u otra encoding de 8 bits), entonces se llevará mejor con git. O tal vez quiera ver esta pregunta sobre las opciones de configuration de git que lo hacen funcionar mejor con los files UTF16.