1 points par GN⁺ 2025-01-20 | 1 commentaires | Partager sur WhatsApp
  • Pourquoi la fonction d’autocorrection de Git est trop rapide

    • La fonction d’autocorrection de Git attend 0,1 seconde avant d’exécuter une commande mal saisie.
    • C’est à peu près la durée d’un clignement d’œil humain, donc un délai auquel il est difficile de réagir.
    • Cette fonctionnalité vient d’un malentendu sur l’unité de temps proposée par un mainteneur de Git et d’un paramétrage inadapté.
  • Comment cette fonctionnalité a-t-elle été conçue ?

    • Par défaut, Git n’exécute pas les commandes mal saisies.
    • Son comportement par défaut consiste à suggérer une commande proche puis à quitter.
    • En 2008, Johannes Schindelin a introduit un patch qui recherche une commande proche et l’exécute.
    • Alex Riesen a ensuite rendu cela configurable via le réglage help.autocorrect.
    • Si help.autocorrect est défini sur 1, Git exécute la commande après 0,1 seconde.
  • Quelle est la bonne valeur de configuration ?

    • Avec 10, Git attend 1 seconde.
    • D’après la documentation, les valeurs possibles sont les suivantes :
      • 0 : affiche la commande suggérée.
      • valeur positive : exécute la commande après le nombre indiqué de tranches de 0,1 seconde.
      • immediate : exécute immédiatement la commande.
      • prompt : affiche la commande suggérée et demande confirmation avant exécution.
      • never : n’exécute ni n’affiche la commande suggérée.
    • Le réglage prompt est peut-être le plus raisonnable.
  • Comment Git fait-il sa supposition ?

    • Git utilise un simple algorithme de distance de Levenshtein modifiée pour deviner la commande.
    • Au-delà d’une certaine distance, Git ne fait aucune supposition.
    • Par exemple, git bass est interprété comme rebase, mais bassa ne l’est pas.
  • Mon petit correctif

    • J’ai écrit un petit patch pour que la valeur 1 soit interprétée comme « immédiat ».
    • Le mainteneur de Git a demandé que toutes les chaînes booléennes soient correctement interprétées.
    • Si ce patch est intégré, les futures versions de Git ne mettront plus votre temps de réaction à l’épreuve.

1 commentaires

 
GN⁺ 2025-01-20
Commentaire Hacker News
  • L’anecdote selon laquelle Hal Finney, lorsqu’il écrivait un interpréteur BASIC pour le système Mattel Intellivision dans les années 70, avait raccourci les messages d’erreur en « EH? », est amusante

  • Le problème vient d’un nom de configuration peu clair. Il aurait fallu un nom explicite comme help.autocorrect_enabled

    • Le nom du paramètre devrait inclure l’unité. Par exemple, il vaudrait mieux nommer int timeout_msec plutôt que int timeout
  • Cela semble être une mauvaise conception. Il faut éviter de modifier le sens d’une valeur de configuration existante en la réinterprétant

    • Ce n’est pas une bonne idée que l’argument de configuration de help.autocorrect soit mesuré dans une unité non standard. Il serait préférable d’utiliser un booléen et un nombre décimal
  • C’est un bon exemple de « creeping featurism ». Cela introduit une complexité inutile

  • L’usage des décisecondes n’a pas été discuté. xmobar rencontre aussi un problème similaire

    • Un petit nombre peut être pris à tort pour des secondes plutôt que pour des millisecondes
  • Si help.autocorrect est réglé sur 1, l’exécution continue après une attente de 100 ms. Il aurait fallu ajouter un nouveau paramètre

    • innodb_flush_log_at_trx_commit de MySQL contient lui aussi une erreur comparable
  • Lorsqu’on règle l’autocorrection sur 3 secondes, elle ne distingue pas les actions dangereuses des actions sûres, et l’historique du shell se retrouve pollué par des commandes mal saisies

    • La décision de la désactiver a été prise un an plus tard
  • En cas d’erreur de frappe dans une commande, on peut appuyer immédiatement sur ctrl-C pour annuler avant l’expiration du délai de 100 ms

  • La déciseconde est une unité non standard. Il est plus courant d’indiquer un délai en millisecondes ou en secondes

  • Le temps de réaction varie selon le type de stimulus. L’audition est plus rapide que la vision, et le toucher est le plus rapide (90 - 180 ms)