git, msysgit, acentos, utf-8, as respostas definitivas

Eu li em alguns lugares que há problemas com git (ou apenas msysgit?) E codificação de caracteres – eu acredito que é apenas um problema em nomes de arquivos.

O que eu gostaria é de algumas informações ‘definitivas’ (ou pelo menos autoritativas) sobre:

  1. Quais são exatamente os ‘problemas’? (Os sintomas)
  2. Quais são as causas? (Brevemente)
  3. Em que cenários isso é um show stopper?
  4. Existe alguma resolução à vista, ou não há soluções alternativas?

Espero que esta pergunta não seja muito vaga, eu acho que seria bom ter todas essas informações em um só lugar para poder apontar as pessoas para isso …

Atualização de fevereiro de 2017 (Git 2.12): A tabela de largura de caracteres foi atualizada para corresponder ao Unicode 9.0 .
O update_unicode.sh é movido para o contrib/update-unicode : veja seu README .

Atualização de agosto de 2014 (git 2.1): commit a67c821 ( Torsten Bögershausen (tboegi) ) adiciona suporte ao Unicode 7.0.

Atualização de abril de 2014: commit d813ab9 ( Torsten Bögershausen (tboegi) ) adiciona suporte ao Unicode 6.3
(git 1.9.2):

O Unicode 6.3 define mais pontos de código como combinação ou acentos .
Por exemplo, o caractere ” ö ” pode ser expresso como ” o ” seguido por U+0308 COMBINING DIARESIS (também conhecido como trema, ponto duplo acima).
Devemos considerar que essa sequência de dois pontos de código ocupa uma coluna de exibição para fins de alinhamento e, para isso, git_wcwidth() deve retornar 0 para eles.

Codepoints afetados são:

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

Padrões anteriores de unicode definiram estes como “reservados”.

Somente o intervalo 0..U+07FF foi verificado para ver quais pontos de código precisam ser marcados como 0-width enquanto se preparam para este commit; mais atualizações podem ser necessárias.


Atualização de abril de 2012: o suporte a Unicode é lançado na versão 1.7.10. Veja esta página para annotations e configurações que você deve definir.

Nomeadamente:

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

O comando recodetree check examina todo o histórico de um repository git e imprime todos os nomes de arquivos não-ASCII. Se a saída estiver vazia, nenhuma migration será necessária.


Atualização de fevereiro de 2012: os patches para os suportes UTF-8 estão chegando no branch ‘devel’ do repository msysgit no GitHub , incluindo Update less settings for UTF-8 .

A página do Git para Windows no Google+ menciona:

Os patches UTF-8 da Karsten Blees para o Git for Windows foram agora integrados ao ‘ devel ‘.
Isso significa que a próxima versão suportará nomes de arquivos Unicode!


Maio de 2011

Eu acredito que o problema msysgit 80 tem o mais recente sobre esse bug.
Também descrito na edição 376 .

Por exemplo:

Isto é o que acontece:

  1. O git no Windows opera em nomes de arquivos e os trata essencialmente como streams de bytes. No seu caso, os streams são textos codificados em UTF8.

  2. git no Windows pede ao tempo de execução para criar um arquivo e passa o stream de bytes.

  3. Como internamente no Windows tudo é Unicode, o tempo de execução converte o stream de bytes em UTF16 usando a localidade atualmente definida (também conhecida como “codepage”).
    Ou seja, ele efetivamente interpreta o stream de bytes como texto codificado CP949 (coreano).
    Aparentemente, algumas das seqüências de bytes UTF8 são sequências CP949 inválidas e a conversão falha (“argumento inválido”); ou se as sequências UTF8 forem sequências CP949 corretas, o resultado é (muito provavelmente) um caractere diferente.

A verdadeira correção deve estar no MingW embora :

Ocorre-me que uma solução seria esta: resolvê-lo no nível da biblioteca de tempo de execução do GCC C.
Ou seja, para a biblioteca de tempo de execução do GCC do mingw no Windows, possibilite, por meio de opções de tempo de construção, estar em um modo em que os parâmetros de linha de comando (passados ​​para main() ) e as funções de E / S de arquivo usem o Windows subjacente. Chamadas de API Unicode e conversão para / de codificação UTF-8 nas APIs de function padrão de C que usam sequências de bytes.
Isso “apenas funcionaria” para o git, e poderia ser útil para outros projetos de código aberto de origem Linux que executam o ambiente Windows.

ak2 comenta que o MingW não é o lugar certo para essa correção:

“Os compiladores MinGW fornecem access à funcionalidade do tempo de execução do Microsoft C e a alguns tempos de execução específicos do idioma.
O MinGW, sendo o Minimalist, não tenta, e nunca tentará, fornecer um ambiente de tempo de execução POSIX para a implementação de aplicativos POSIX no MS-Windows.
Se você quiser a implementação do aplicativo POSIX nesta plataforma, por favor, considere o Cygwin. ”

Há algum trabalho em andamento em uma variante msysgit para oferecer suporte ao unicode .