git, msysgit, acentos, utf-8, las respuestas definitivas

Question

He leído en algunos lugares que hay problemas con git (o simplemente msysgit?) Y la codificación de caracteres - I creo es solo un problema en los nombres de archivos .

Lo que me gustaría es un poco de información 'definitivo' (o al menos autorizada) sobre: ​​

1. ¿Cuáles son exactamente los 'problemas'? (Los síntomas)
2. ¿Cuáles son las causas? (En breve)
3. ¿En qué escenarios es este un tapón de espectáculo?
4. ¿Hay alguna resolución a la vista, o en su defecto, alguna solución alternativa?

espero que esta pregunta no es demasiado vaga, creo que sería bueno tener toda esta información en un solo lugar para poder señalar a la gente a que ...

Answer 1

actualización de febrero 2017 (Git 2.12): la tabla de ancho de caracteres se ha actualizado para que coincida con Unicode 9.0.
El update_unicode.sh es moved it into contrib/update-unicode: vea its README.

Actualización de agosto de 2014 (git 2.1): commit a67c821 (Torsten Bögershausen (tboegi)) agrega compatibilidad con Unicode 7.0.

Update Abril 2014: commit d813ab9 (Torsten Bögershausen (tboegi)) añade soporte para Unicode 6.3
(Git 1.9.2):

Unicode 6.3 define más puntos de código como la combinación de acentos o.
Por ejemplo, el carácter "ö" podría expresarse como "o" seguido de U+0308 COMBINING DIARESIS (alias umlaut, doble punto-arriba).
Deberíamos considerar que dicha secuencia de dos puntos de código ocupa una columna de visualización para fines de alineación, y para eso, git_wcwidth() debería devolver 0 para ellos.

puntos de código afectados son:

U+0358..U+035C 
U+0487 
U+05A2, U+05BA, U+05C5, U+05C7 
U+0604, U+0616..U+061A, U+0659..U+065F 

A principios de los estándares de Unicode habían definido estos como "reservado".

Solo se ha verificado el rango 0..U+07FF para ver qué puntos de código deben marcarse como ancho 0 mientras se prepara para esta confirmación; Se pueden necesitar más actualizaciones.

---

Actualización de abril de 2012: El soporte Unicode se libera en la versión 1.7.10. Consulte this page para obtener notas y configuraciones que debe establecer.

A saber:

git config [--global] core.quotepath off 
git config [--global] i18n.logoutputencoding utf8 
git config [--global] i18n.commitencoding utf8 
git config [--global] --unset svn.pathnameencoding 

El comando recodetree check escanea toda la historia de un repositorio Git y grabados los nombres de archivos no ASCII.Si la salida está vacía, no es necesaria la migración.

---

Actualización de febrero de 2012: parches para UTF-8 soportes están viniendo en la rama 'devel' de msysgit repo on GitHub, incluyendo Update less settings for UTF-8.

El Git para la página de Windows menciones de Google+:

Karsten Blees' UTF-8 parches para Git para Windows Ahora se ha fusionado a 'devel'.
Esto significa que la próxima versión será compatible con los nombres de archivo Unicode!

---

de mayo de 2011

creo que el msysgit issue 80 tiene el más reciente sobre ese error.
También se describe en issue 376.

Por ejemplo:

Esto es lo que sucede:

1. Git en Windows funciona con nombres de archivo y los trata esencialmente como flujos de bytes. En su caso, las secuencias son texto codificado en UTF8.

2. git en Windows le pide al tiempo de ejecución que cree un archivo y lo pasa la secuencia de bytes.

3. Dado que internamente en Windows todo es Unicode, el tiempo de ejecución convierte la secuencia de bytes a UTF16 utilizando la configuración regional actualmente establecida (también conocida como "codepage").
   Es decir, interpreta eficazmente la secuencia de bytes como texto codificado CP949 (coreano).
   Aparentemente, algunas de las secuencias de bytes UTF8 son secuencias CP949 no válidas, y la conversión falla ("argumento inválido"); o si las secuencias UTF8 son secuencias correctas de CP949, el resultado es (muy probablemente) un personaje diferente.

La verdadera solución debe estar en MingW aunque:

Se me ocurre que una solución sería la siguiente: a resolverlo en el GCC C en tiempo de ejecución nivel de la biblioteca.
Es decir, para la biblioteca de tiempo de ejecución mingw GCC en Windows, haga posible a través de opciones de tiempo de compilación estar en un modo donde los parámetros de línea de comandos (pasado a main()) y las funciones de E/S de archivo utilizan el Windows subyacente Llamadas a la API Unicode y traducción a/desde la codificación UTF-8 en las API de función estándar de C que usan cadenas de bytes.
Eso simplemente "funcionaría" para git, y podría ser útil para otros proyectos de código abierto originados en Linux que ejecutan el entorno de Windows.

ak2 comentarios que MingW no es el lugar adecuado para esta revisión:

"compiladores MinGW proporcionan acceso a la funcionalidad de la ejecución de Microsoft C y unos tiempos de ejecución específicos del idioma
MinGW,. siendo minimalista, no intenta y nunca intentará proporcionar un entorno de tiempo de ejecución POSIX para la implementación de la aplicación POSIX en MS-Windows.
Si desea implementar la aplicación POSIX en esta plataforma, considere Cygwin en su lugar ".

Hay algunos trabajos en progreso en un msysgit variant to support unicode.