Warum Git Autocorrect für Formel-1-Fahrer zu schnell ist

• Warum die automatische Korrekturfunktion von Git zu schnell ist

  • Die Autokorrektur von Git wartet 0,1 Sekunden, bevor sie einen falsch eingegebenen Befehl ausführt.
  • Das entspricht ungefähr der Zeit eines menschlichen Lidschlags und ist daher schwer, rechtzeitig zu stoppen.
  • Diese Funktion entstand aus einem Missverständnis über die Zeiteinheit, das ein Git-Maintainer vorschlug, sowie aus einer fehlerhaften Konfiguration.

• Wie wurde diese Funktion entworfen?

  • Standardmäßig führt Git falsch eingegebene Befehle nicht aus.
  • Das Standardverhalten besteht darin, ähnliche Befehle vorzuschlagen und dann zu beenden.
  • 2008 führte Johannes Schindelin einen Patch ein, der ähnliche Befehle findet und ausführt.
  • Alex Riesen machte dies über die Einstellung help.autocorrect konfigurierbar.
  • Wenn help.autocorrect auf 1 gesetzt ist, wird der Befehl nach 0,1 Sekunden ausgeführt.

• Welcher Einstellungswert ist angemessen?

  • Wenn man 10 setzt, wartet Git 1 Sekunde.
  • Laut Dokumentation sind folgende Werte möglich:
    • 0: zeigt den vorgeschlagenen Befehl an.
    • positive Werte: führt den Befehl nach der angegebenen Anzahl von 0,1 Sekunden aus.
    • immediate: führt den Befehl sofort aus.
    • prompt: zeigt den vorgeschlagenen Befehl an und fragt per Prompt, ob er ausgeführt werden soll.
    • never: führt den vorgeschlagenen Befehl weder aus noch zeigt Git ihn an.
  • Die Einstellung prompt könnte die vernünftigste sein.

• Wie rät Git?

  • Git verwendet einen einfachen modifizierten Levenshtein-Distanz-Algorithmus, um Befehle zu erraten.
  • Ab einer bestimmten Distanz wird nicht mehr geraten.
  • Zum Beispiel wird git bass als rebase erraten, bassa jedoch nicht.

• Meine kleine Korrektur

  • Ich habe einen kleinen Patch geschrieben, der den Wert 1 als „sofort“ interpretiert.
  • Der Git-Maintainer bat darum, alle booleschen String-Werte korrekt zu interpretieren.
  • Wenn dieser Patch übernommen wird, werden künftige Git-Versionen die Reaktionsgeschwindigkeit der Nutzer nicht mehr auf die Probe stellen.

[GN⁺]

Hacker-News-Kommentare

• Die Anekdote ist amüsant, dass Hal Finney in den 70ern beim Schreiben eines BASIC-Interpreters für das Mattel-Intellivision-System Fehlermeldungen auf „EH?“ verkürzt hat

• Probleme entstehen, weil der Name der Einstellung nicht eindeutig ist. Ein klarer Name wie help.autocorrect_enabled wäre nötig gewesen

  • Der Name der Einstellung sollte die Einheit enthalten. Zum Beispiel sollte man statt int timeout eher int timeout_msec verwenden

• Wirkt wie ein schlechtes Design. Man sollte vermeiden, bestehende Einstellungswerte durch Neuinterpretation zu verändern

  • Es ist keine gute Idee, dass das Konfigurationsargument von help.autocorrect in einer nicht standardmäßigen Einheit gemessen wird. Besser wäre eine Einstellung als Boolean und Dezimalzahl

• Ein gutes Beispiel für „creeping featurism“. Das führt zu unnötiger Komplexität

• Die Verwendung von Dezisekunden wurde nicht diskutiert. Auch xmobar hat ein ähnliches Problem

  • Kleine Zahlen können fälschlich als Sekunden statt als Millisekunden verstanden werden

• Wenn help.autocorrect auf 1 gesetzt wird, geht es nach 100 ms Wartezeit weiter. Man hätte eine neue Einstellung hinzufügen sollen

  • Auch MySQLs innodb_flush_log_at_trx_commit enthält einen ähnlichen Fehler

• Wenn autocorrect auf 3 Sekunden gesetzt ist, wird nicht zwischen gefährlichem und sicherem Verhalten unterschieden, und die Shell-Historie wird durch falsch eingegebene Befehle verschmutzt

  • Nach einem Jahr fiel die Entscheidung, es zu deaktivieren

• Wenn man einen Befehl falsch eingibt, kann man sofort ctrl-C drücken und vor dem 100-ms-Timeout abbrechen

• Dezisekunden sind keine standardmäßige Einheit. Üblicher ist es, Verzögerungen in Millisekunden oder Sekunden anzugeben

• Reaktionszeiten unterscheiden sich je nach Art des Reizes. Hören ist schneller als Sehen, und Tastsinn ist am schnellsten (90–180 ms)