Por que o Git Autocorrect é rápido demais até para um piloto de Fórmula 1

• Por que o recurso de autocorreção do Git é rápido demais

  • O recurso de autocorreção do Git espera 0,1 segundo antes de executar um comando digitado incorretamente.
  • Isso é semelhante ao tempo de um piscar de olhos humano, tornando difícil reagir.
  • Esse recurso surgiu de um mal-entendido sobre a unidade de tempo proposta por um mantenedor do Git e de uma configuração incorreta.

• Como esse recurso foi projetado?

  • Por padrão, o Git não executa comandos digitados incorretamente.
  • O comportamento padrão é sugerir comandos parecidos e encerrar.
  • Em 2008, Johannes Schindelin introduziu um patch que encontrava e executava comandos parecidos.
  • Alex Riesen tornou isso configurável por meio da opção help.autocorrect.
  • Definir help.autocorrect como 1 faz com que o comando seja executado após 0,1 segundo.

• Qual é o valor de configuração adequado?

  • Se definido como 10, ele espera 1 segundo.
  • Segundo a documentação, os valores configuráveis são:
    • 0: mostra o comando sugerido.
    • positivo: executa o comando após o número especificado de intervalos de 0,1 segundo.
    • immediate: executa o comando imediatamente.
    • prompt: mostra o comando sugerido e exibe um prompt perguntando se deve executá-lo.
    • never: não executa nem mostra o comando sugerido.
  • A configuração prompt pode ser a mais sensata.

• Como o Git adivinha?

  • O Git usa um algoritmo simples de distância de Levenshtein modificada para adivinhar o comando.
  • Acima de uma certa distância, ele deixa de fazer a suposição.
  • Por exemplo, git bass é interpretado como rebase, mas bassa não é.

• Minha pequena correção

  • Foi escrito um pequeno patch para interpretar o valor 1 como "imediato".
  • O mantenedor do Git pediu que todos os valores booleanos em forma de string fossem interpretados corretamente.
  • Se esse patch for aceito, versões futuras do Git não vão mais testar seu tempo de reação.

[GN⁺]

Comentários do Hacker News

• É engraçada a história de que Hal Finney, ao escrever um interpretador BASIC para o sistema Mattel Intellivision nos anos 70, reduziu a mensagem de erro para "EH?"

• O problema surgiu porque o nome da configuração não era claro. Era necessário um nome mais explícito, como help.autocorrect_enabled

  • O nome da configuração deveria incluir a unidade. Por exemplo, deveria ser nomeado como int timeout_msec em vez de int timeout

• Parece um design ruim. Deve-se evitar reinterpretar um valor de configuração existente para mudar seu comportamento

  • Não é bom que o argumento de configuração de help.autocorrect seja medido em uma unidade não padrão. O ideal seria configurá-lo com booleano e decimal

• É um bom exemplo de "creeping featurism". Isso causa complexidade desnecessária

• Não houve discussão sobre o uso de decissegundos. O xmobar também está passando por um problema semelhante

  • Números pequenos podem ser confundidos com segundos, e não milissegundos

• Se a configuração help.autocorrect for definida como 1, ele prossegue após esperar 100 ms. Deveriam ter adicionado uma nova configuração

  • innodb_flush_log_at_trx_commit do MySQL também inclui um erro parecido

• Quando o autocorrect foi configurado para 3 segundos, ele não conseguiu distinguir entre ações perigosas e seguras, e o histórico do shell foi poluído com comandos digitados incorretamente

  • Um ano depois, foi tomada a decisão de desativá-lo

• Ao digitar um comando errado, é possível cancelar antes do timeout de 100 ms pressionando ctrl-C imediatamente

• Decissegundos são uma unidade não padrão. É mais comum especificar o atraso em milissegundos ou segundos

• O tempo de reação varia conforme o tipo de estímulo. A audição é mais rápida que a visão, e o tato é o mais rápido (90 - 180 ms)