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

Question

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

Lo que me gustaría es alguna información ''definitiva'' (o al menos autoritaria) sobre:

1. ¿Cuáles son exactamente los "problemas"? (Los síntomas)
2. ¿Cuales son las causas? (Brevemente)
3. ¿En qué escenarios es esto un show stopper?
4. ¿Hay alguna resolución a la vista, o en su defecto cualquier solución alternativa?

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

Answer 1

Actualización de febrero de 2017 (Git 2.12): la tabla de ancho de caracteres se ha actualizado para que coincida con Unicode 9.0 .
El update_unicode.sh se mueve a contrib/update-unicode : vea su archivo README .

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

Actualización de abril de 2014: commit d813ab9 ( Torsten Bögershausen (tboegi) ) agrega soporte para Unicode 6.3
(git 1.9.2):

Unicode 6.3 define más puntos de código como combinación o acentos .
Por ejemplo, el carácter " ö " podría expresarse como una " o " seguida de U+0308 COMBINING DIARESIS (también conocido como umlaut, double-dot-above).
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.

Los 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

Los estándares Unicode anteriores los habían definido como "reservados".

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 este compromiso; Se pueden necesitar más actualizaciones.

Actualización de abril de 2012: compatibilidad con Unicode en la versión 1.7.10. Consulte esta página para conocer las notas y la configuración 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 todo el historial de un repositorio de git e imprime todos los nombres de archivo que no sean ASCII. Si la salida está vacía, no es necesaria la migración.

Actualización de febrero de 2012: los parches para los soportes UTF-8 están llegando en la rama ''desarrollo'' de msysgit repo en GitHub , incluida la actualización de menos configuraciones para UTF-8 .

La página de Git for Windows Google+ menciona:

Los parches UTF-8 de Karsten Blees para Git para Windows ahora se han combinado a '' devel ''.
¡Esto significa que la próxima versión admitirá nombres de archivo Unicode!

Mayo de 2011

Creo que el número 80 de msysgit tiene lo último sobre ese error.
También se describe en el número 376 .

Por ejemplo:

Esto es lo que pasa:

1. git en Windows opera en nombres de archivos 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 configurada (también conocida como "página de códigos").
   Es decir, interpreta efectivamente el flujo 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 debería estar en MingW aunque :

Se me ocurre que una solución sería esta: resolverla en el nivel de biblioteca de tiempo de ejecución GCC C.
Es decir, para la biblioteca de tiempo de ejecución de mingw GCC en Windows, permite a través de las opciones de tiempo de compilación estar en un modo donde los parámetros de línea de comandos (pasados ​​a main() ) y las funciones de E / S de archivo usan 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 "solo funcionaría" para git, tal vez, y podría ser útil para otros proyectos de código abierto originados en Linux que ejecutan el entorno de Windows.

ak2 comenta que MingW no es el lugar correcto para esta solución:

"Los compiladores MinGW brindan acceso a la funcionalidad del tiempo de ejecución C de Microsoft y algunos tiempos de ejecución específicos del idioma.
MinGW, al ser minimalista, no intenta, ni 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 algo de trabajo en progreso en una variante de msysgit para admitir Unicode .