Why is Git Autocorrect too fast for Formula One drivers?
39 comments
·January 19, 2025userbinator
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.
pmontra
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.
Reason077
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.
politelemon
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.
misnome
Yes, absolutely this. If I don’t want it to run, I will hit ctrl-c.
kittikitti
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.
schacon
I'm curious if the startup time, plus the overhead of Git trying to figure out what you might have meant is significant enough to give you enough time to realize and hit ctrl+c. In testing it quickly, it looks like typing the wrong command and having it spit out the possible matches without running it takes 0.01-0.03s, so I would venture to guess that it's still not enough time between hitting enter and then immediately hitting ctrl-c, but maybe you're very very fast?
rad_gruchalski
The command is already running, you ctrl+c THE command. But I agree, 100ms is short.
cardamomo
Reading this post, the term "software archeology" and "programmer archeologist" come to mind. (Thank you, Vernor Vinge, for the latter concept.)
choult
I like to say that the danger of software archaeology is the inevitable discovery of coprolites...
schacon
I can’t help but feel like you’re calling me “old”…
dusted
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.
SOLAR_FIELDS
100 ms is an insanely short window. I would say usually even 1000ms would be too short for me to recognize and kill the command, even if I realized immediately that I had done something wrong.
jsjshsbd
It's much too short to read an output, interpret it and realize you have to interrupt
But often you type something, realize it's wrong while you are typing but not fast enough to stop your hand from pressing [Enter]
That is one of the only situation 100ms would be enough to safe you
That being said, the reason in the article for 100ms is just confused commander. Why would anyone:
1) encode a Boolean value as 0/1 in a human readable configuration 2) encode a duration as a numeric value without unit in a human readable configuration
Both are just lazy
Reason077
> "Why would anyone ... encode a Boolean value as 0/1 in a human readable configuration"
It may be lazy, but it's very common!
Etheryte
Maybe worth noting here that 100ms is well under the human reaction time. For context, professional sprinters have been measured to have a reaction time in the ballpark of 160ms, for pretty much everyone else it's higher. And this is only for the reaction, you still need to move your hand, press the keys, etc.
shawabawa3
In this case the reaction starts before you hit enter, as you're typing the command
So, you type `git pshu<enter>` and realise you made a typo before you've finished typing. You can't react fast enough to stop hitting enter but you can absolutely ctrl+c before 100 more ms are up
mscdex
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.
1970-01-01
Deciseconds?? There's your problem. Always work in seconds when forcing a function for your users.
synecdoche
This may be something specific to Japan, which is where the maintainer is from. In the Japanese industrial control systems that I’ve encountered time is typically measured in this (100ms) unit.
gruez
better yet, encode the units into the variable/config name so people don't have to guess. You wouldn't believe how often I have to guess whether "10" means 10 seconds (sleep(3) in linux) or milliseconds (Sleep in win32).
dusted
at least fractions of a second, 250 would already be much more noticble.. 100 is a nice compromise between "can't react" and "have to wait", assuming you're already realizing you probably messed up
331c8c71
Seconds or milliseconds (e.g. if the setting must be integer) would've been fine as they are widely used. Deciseconds, centiseconds - wtf?
atonse
Falls squarely within the "They were too busy figuring out whether they could do it, to ask whether they SHOULD do it"
UndefinedRef
Maybe he meant dekaseconds? Still weird though..
schacon
We had this debate internally at GitButler. Deci versus deca (and now deka, which appears to also be a legit spelling). My assumption was that 1 full second may have felt too long, but who really knows.
a3w
deci is 1/10, deca is 10/1. So decisecond is correct.
TonyTrapp
It reads like the intention was that turning the parameter (0/1) command into an integer parameter, where the previous value enabled = 1 should behave reasonably close to the old behaviour. 1 deciseconds is arguably close enough to instant. If the parameter were measured in seconds, the command would always have to wait a whole second before executing, with no room for smaller delays.
Theodores
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'?
mike-the-mikado
I'd be interested to know if any F1 drivers actually use git.
schacon
Not sure, but I do personally know two high profile Ruby developers who regularly race in the LMP2 (Le Mans Prototype 2) class - DHH and my fellow GitHub cofounder PJ Hyett, who is now a professional driver, owning and racing for AO (https://aoracing.com/).
I mostly say this because I find it somewhat fun that they have raced _each other_ at Le Mans last year, but also because I've personally seen both of them type Git commands, so I know it's true.
pacaro
I've also worked with engineers who have raced LMP. It's largely pay-to-play and this is one of those professions where if you're the right person, in the right place, at the right time, you might be able to afford it.
null
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.