Why is Git Autocorrect too fast for Formula One drivers?

> Originally, if you typed an unknown command, it would just say "this is not a git command".

Back in the 70s, Hal Finney was writing a BASIC interpreter to fit in 2K of ROM on the Mattel Intellivision system. This meant every byte was precious. To report a syntax error, he shortened the message for all errors to:

    EH?

I still laugh about that. He was quite proud of it.

The root cause here is poorly named settings.

If the original setting had been named something bool-y like `help.autocorrect_enabled`, then the request to accept an int (deciseconds) would've made no sense. Another setting `help.autocorrect_accept_after_dsec` would've been required. And `dsec` is so oddball that anyone who uses it would've had to look up.

I insist on this all the time in code reviews. Variables must have units in their names if there's any ambiguity. For example, `int timeout` becomes `int timeout_msec`.

This is 100x more important when naming settings, because they're part of your public interface and you can't ever change them.

  void FooBar(std::chrono::milliseconds timeout);

  auto timeout = gl_timeout; // or GetTimeoutFromSomewhere().
  FooBar(timeout);

> Now, why Junio thought deciseconds was a reasonable unit of time measurement for this is never discussed, so I don't really know why that is.

xmobar uses deciseconds in a similar, albeit more problematic place - to declare how often to refresh each section. Using deciseconds is fantastic if your goal is for example configs to have numbers small enough that they clearly can't be milliseconds, resulting in people making the reasonable assumption that it must thus be seconds, and running their commands 10 times as often as they intended to. I've seen a number of accidental load spikes originating from this issue.

This seems like really quite bad design.

EDIT: 1) is the result of my misreading of the article, the "previous value" never existed in git.

1) Pushing a change that silently break by reinterpreting a previous configuration value (1=true) as a different value (1=0.100ms confirmation delay) should pretty much always be avoided. Obviously you'd want to clear old values if they existed (maybe this did happen? it's unclear to me), but you also probably want to rename the configuration label..

2) Having `help.autocorrect`'s configuration argument be a time, measured in a non-standard (for most users) unit, is just plainly bad. Give me a boolean to enable, and a decimal to control the confirmation time.

IMHO this is a great example of "creeping featurism". At best it introduces unnecessary complexity, and at worst those reliant on it will be encouraged to pay less attention to what they're doing.

> Which was what the setting value was changed to in the patch that was eventually accepted. This means that setting help.autocorrect to 1 logically means "wait 100ms (1 decisecond) before continuing".

The mistake was here. Instead of retargeting the existing setting for a different meaning, they should have added a new setting.

    help.autocorrect - enable or disable
    help.autocorrect.milliseconds - how long to wait

There are similar mistakes in other systems, e.g., MySQL has

    innodb_flush_log_at_trx_commit

which can be 0 if disabled, 1 if enabled, and 2 was added as something special.

I enabled autocorrect (set a 3sec) a year ago and have the following observations about it:

1. it does not distinguish between dangerous and safe actions

2. it pollutes my shell history with mistyped commands

Reading this article gave me just enough of a nudge to just disable it after a year.

Deciseconds is such an oddball choice of units. Better to specify the delay in either milliseconds or seconds - either are far more commonly used in computing.

Reaction times differ by types of stimulus, auditory is slightly faster than visual and tactile slightly faster than that at 90 - 180 ms So if git gave you a slap instead of an error message you might just about have time to react.

Reading this post, the term "software archeology" and "programmer archeologist" come to mind. (Thank you, Vernor Vinge, for the latter concept.)

I sometimes have this realization as I'm pressing enter and reflexively press ctrl+c. As someone whose typing speeds range from 100 to 160 WPM, this makes sense. Pressing keys is much different from Formula One pit stops.

I think it makes sense, if I typed something wrong, I often feel it before I can read it, but if I already pushed enter, being able to ctrl+c within 100 ms is enough to save me. I'm pretty sure I've also aborted git pushes before they touched anything before I put this on, but this makes it more reliable.

For reference, Valtteri Bottas supposedly recorded a 40ms!!! reaction time at the 2019 Japanese Grand Prix.

https://www.formula1.com/en/video/valtteri-bottas-flying-fin...

0.1 seconds is a long time in drag racing where the timing tree is very different to F1. With F1 there are the five red lights that have to go out, and the time this takes is random.

With your git commands it is fairly predictable what happens next, it is not as if the computer is randomly taunting you with five lights.

I suggest a further patch where you can put git in either 'F1 mode', or, for our American cousins, 'Drag Strip mode'. This puts it in to a confirmation mode for everything, where the whole timing sequence is shown in simplified ASCII art.

As a European, I would choose 'F1 mode' to have the give lights come on in sequence, wait a random delay and then go out, for 'git push' to happen.

I see no reason to also have other settings such as 'Ski Sunday mode', where it does the 'beep beep beep BEEEP' of the skiing competition. 'NASA mode' could be cool too.

Does anyone have any other timing sequences that they would like to see in the next 'patch'?

I agree that 'prompt' should be the value to set if you want git autocorrect to work for you. I'd however want that the Y is the default rather than the N, so that a user can just press enter once they've confirmed it.

In any case it is not a good idea to have a CLI command happen without your approval, even if the intention was really obvious.

> Junio came back to request that instead of special casing the "1" string, we should properly interpret any boolean string value (so "yes", "no", "true", "off", etc)

The fact that this guy has been the Git maintainer for so long and designs settings like this explains a lot!

Deciseconds?? There's your problem. Always work in seconds when forcing a function for your users.

The most baffling thing is that someone implemented deciseconds as a unit of time. Truly bizarre.

This timeout makes me think about the type of scenario where I know I have mistyped the command, e.g. because I accidentally hit return prematurely, or hit return when I was trying to backspace away a typo. In those situations I reflexively follow return with an immediate ctrl-C, and might be able to get in before the 100 ms timeout. So it’s not entirely useless!

> As some of you may have guessed, it's based on a fairly simple, modified Levenshtein distance algorithm

One day it'll dump the recent bash and git history into an LLM that will say something along the lines of "alright dumbass here's what you actually need to run"

> introduced a small patch

> introduced a patch

> the Git maintainer, suggested

> relatively simple and largely backwards compatible fix

> version two of my patch is currently in flight to additionally

And this is how interfaces become unusable, through thousand small "patches" created without any planning and oversight.

Cool but I don't know why it needs to be justified that it's too fast even for an F1 driver. Why can't we just say its too fast without all the fluff about being a race car driver, the guy isn't even an F1 driver but Le Mans.

Git autocorrect sounds like a very bad idea.

According to Formula 1 web site drivers start on average after 0.2 seconds since the red lights go out https://www.formula1.com/en/latest/article/rapid-decisions-d...

Anyway, 0.1 seconds would be far too short even for them, which have a job based on fast reaction times.

So Mercurial had something like this back in ancient times, but git devs decided to make a worse implementation.

Pet peeve: Timespan configs that don't include the unit in the variable name.

I'm so sick of commands with --timeout params where I'm left guessing if it's seconds or millis or what.

I'd be interested to know if any F1 drivers actually use git.

Really enjoyable read

Regardless of the delay time, this just seems like an incredibly bad idea all around for something as important as source control.

Fun fact: Professional gamers (esport players) have reaction times around 150ms to 170ms. 100ms is more or less impossible.

This seems a bit strange to me considering the default behavior is to only show a suggested command if possible and do nothing else. That means they explicitly opted into the autocorrect feature and didn't bother to read the manual first and just guessed at how it's supposed to be used.

Even the original documentation for the feature back when it was introduced in 2008 (v1.6.1-rc1) is pretty clear what the supported values are and how they are interpreted.

Whenever you provide a time configuration option, field, or parameter, always encode the units into the name.

First time I hear about deciseconds. What a strange decision.

At 60fps that's 6 frames, which is plenty.

That aside, I feel the reason is to advertise the feature so that the user gets a chance to set the timer up to his preference or disable autocorrect entirely.

Maybe a not-so-hot take on this... The only option this configuration parameter should take is "never", which should also be the default. Any other value should be interpreted as "never".

What if this was an intentional, yet overly clever, way to avoid one special case?

I mean, for all practical purposes, the value of 1 equals to the unconditional execution.

Yet another example where git shows its lack of user-friendly design

clickbait, don't hide the truth in a pseudo-riddle