Por qué el Autocorrect de Git es demasiado rápido para un piloto de Fórmula 1

• Por qué la función de autocorrección de Git es demasiado rápida

  • La función de autocorrección de Git espera 0.1 segundos antes de ejecutar un comando escrito incorrectamente.
  • Esto es similar al tiempo que tarda en parpadear un ojo humano, por lo que es difícil reaccionar a tiempo.
  • Esta función surgió por un malentendido sobre la unidad de tiempo propuesta por un mantenedor de Git y por una configuración equivocada.

• ¿Cómo fue diseñada esta función?

  • Por defecto, Git no ejecuta comandos escritos incorrectamente.
  • El comportamiento predeterminado es sugerir comandos similares y salir.
  • En 2008, Johannes Schindelin introdujo un parche para encontrar y ejecutar comandos similares.
  • Alex Riesen hizo que esto fuera configurable mediante la opción help.autocorrect.
  • Si help.autocorrect se configura en 1, ejecuta el comando después de 0.1 segundos.

• ¿Cuál es el valor de configuración adecuado?

  • Si se configura en 10, espera 1 segundo.
  • Según la documentación, los valores configurables son los siguientes:
    • 0: muestra el comando sugerido.
    • positivo: ejecuta el comando después del número especificado de intervalos de 0.1 segundos.
    • immediate: ejecuta el comando de inmediato.
    • prompt: muestra el comando sugerido y presenta un prompt preguntando si debe ejecutarlo.
    • never: no ejecuta ni muestra el comando sugerido.
  • La configuración prompt podría ser la más razonable.

• ¿Cómo adivina Git?

  • Git usa un algoritmo simple de distancia de Levenshtein modificado para adivinar comandos.
  • Si supera cierta distancia, no hace ninguna suposición.
  • Por ejemplo, git bass se adivina como rebase, pero bassa no se adivina.

• Mi pequeño arreglo

  • Escribí un pequeño parche para interpretar el valor 1 como "inmediato".
  • El mantenedor de Git pidió interpretar correctamente todos los valores booleanos en forma de cadena.
  • Si este parche se aplica, las futuras versiones de Git ya no pondrán a prueba tu tiempo de reacción.

[GN⁺]

Opiniones de Hacker News

• Es divertida la anécdota de cuando Hal Finney, al escribir un intérprete de BASIC para el sistema Mattel Intellivision en los años 70, redujo el mensaje de error a "¿EH?"

• El problema surgió porque el nombre de la configuración no era claro. Hacía falta un nombre más explícito, como help.autocorrect_enabled

  • El nombre de la configuración debería incluir la unidad. Por ejemplo, conviene nombrarlo int timeout_msec en lugar de int timeout

• Parece un mal diseño. Debería evitarse reinterpretar un valor de configuración existente para cambiar su comportamiento

  • No es buena idea que el argumento de configuración de help.autocorrect se mida en una unidad no estándar. Sería preferible configurarlo con un booleano y un decimal

• Es un buen ejemplo de "creeping featurism". Genera complejidad innecesaria

• No se discutió el uso de decisegundos. xmobar también está pasando por un problema parecido

  • Un número pequeño puede malinterpretarse como segundos en vez de milisegundos

• Si help.autocorrect se configura en 1, continúa después de una espera de 100 ms. Deberían haber agregado una configuración nueva

  • innodb_flush_log_at_trx_commit de MySQL también incluye un error similar

• Cuando se configuró el autocorrect en 3 segundos, no distinguía entre acciones peligrosas y seguras, y el historial del shell se contaminaba con comandos mal escritos

  • Un año después, se decidió desactivarlo

• Cuando se escribe mal un comando, se puede presionar ctrl-C de inmediato para cancelarlo antes de que venza el timeout de 100 ms

• Los decisegundos son una unidad no estándar. Es más común especificar la latencia en milisegundos o en segundos

• El tiempo de reacción varía según el tipo de estímulo. El auditivo es más rápido que el visual, y el táctil es el más rápido (90 - 180 ms)