-
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
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_enabledint timeout_msecplutôt queint timeoutCela semble être une mauvaise conception. Il faut éviter de modifier le sens d’une valeur de configuration existante en la réinterprétant
help.autocorrectsoit mesuré dans une unité non standard. Il serait préférable d’utiliser un booléen et un nombre décimalC’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
Si
help.autocorrectest réglé sur 1, l’exécution continue après une attente de 100 ms. Il aurait fallu ajouter un nouveau paramètreinnodb_flush_log_at_trx_commitde MySQL contient lui aussi une erreur comparableLorsqu’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
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)