Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

141–150 of 248 posts

Re: Why is Git Autocorrect too fast for Formula One drivers?

#141

> 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 The…

Not sure where the best place to mention would be, but 0.1 deciseconds is not unreasonable, either...yes fastest recorded random reaction time maybe 1.5 ds (coincidentally this is the average gamer reaction time), however non-random reaction times can be much faster (e.g. on a beat).

So if you wanted to go that fast, you could, the invokation should have relatively stable speeds (order of some milliseconds...

Re: Why is Git Autocorrect too fast for Formula One drivers?

#142

Earlier quoted context omitted.

It was about saving memory by tokenizing keywords: '?' is how PRINT actually was stored in program memory, it just rendered as 'PRINT'. Most other tokens were typically the first two characters, the first lowercase, the second uppercase: I remember LOAD was 'lO' and DATA was 'dA', though on the C64's default character glyphs they usually looked like L and D . All this being on a C64 of course, but I suspect most vers…

C64 basic was tokenized into one byte, with the most significant bit set: https://www.c64-wiki.com/wiki/BASIC_token Each command could be typed in two ways: the full name, or the first two letters, with the second capitalized. Plus a few exceptions like "?" turning into the PRINT token ($99, nowhere near the PETSCII value for ?) and π becoming $FF. The tokens were expanded into full text strings when you would LIST t…

As far as I remember you couldn't even run these programs after listing anymore.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#143

Earlier quoted context omitted.

> But Ctrl+C are two key presses: reacting to type them both in under 100 ms is equivalent to a writting speed above 200WPM. I think people don't really type/press buttons at a constant speed. Instead we do combos. You do a quick one-two punch because that's what you're used to ("you've practiced"). You do it much faster than that 100ms, but after that you get a bit of a delay before you start the next combo.

As menctioned, pro-gamers train combos for hours daily. The best of them can press up to 10 keys per second without thinking. For example, the fastest StarCraft II player Reynor (Riccardo Romitti) can sustain 500 key presses per minute, and do short busts of 800. He has videos explaining how to tweak the Windows registry to achieve such rate (it involves pressing some keys once and the OS autorepeats faster than you…

I actually took you up on this, and best I was able to get was about 250ms when I was really concentrating. Average was around 320!

Re: Why is Git Autocorrect too fast for Formula One drivers?

#144

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…

> 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`.

Personally I flag any such use of int in code reviews, and instead recommend using value classes to properly convey the unit (think Second(2) or Millisecond(2000)).

This of course depends on the language, it's capabilities and norms.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#145

Earlier quoted context omitted.

1 was also accepted as a Boolean true in this context, and it still is in other contexts.

> 1 was also accepted as a Boolean true in this context, and it still is in other contexts. Is "was" before the change described at the end of the article, or after it? Before the change, any positive number implied that the feature is on, because that's the only thing that makes sense. After the change, you could say that 1 stops being treated as a number, but it's simpler to say it's still being treated as a number…

In an earlier iteration the configuration value was Boolean true/false. A 1 was interpreted as true. They changed it to an integral value. This is the entire setup for the problem in the article.

Elsewhere, 1 is still allowed as a true equivalent.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#146
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!

Re: Why is Git Autocorrect too fast for Formula One drivers?

#147

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…

> 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`. Personally I flag any such use of int in code reviews, and instead recommend using value classes to properly convey the unit (think Second(2) or Millisecond(2000)). This of course depends on the language, it's capabilities and norms.

I agree. Any time we start annotating type information in the variable name is a missed opportunity to actually use the type system for this.

I suppose this is the "actual" problem with the git setting, in so far as there is an "actual" problem: the variable started out as a boolean, but then quietly turned into a timespan type without triggering warnings on user configs that got reinterpreted as an effect of that.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#148
post #18

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.

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.

There are different ways to measure reaction time. Circumstance is important.

Reaction to unreasonable, unexpected events will be very slow due to processing and trying to understand what happens and how to respond. Examples, you are a racecar driver, participating in a race, you're driving your car on a racetrack in a peaceful country.

An armed attack: Slow reaction time, identifying the situation will take a long time, selecting an appropriate response will take longer.

A kid running into the road on the far side of the audience stands: Faster.

Kid running into the road near the audience: Faster.

Car you're tailing braking with no turn to come: Faster.

Crashed car behind a turn with bad overview: Faster.

Guy you're slipstreaming braking before a turn: Even faster.

For rhythm games, you anticipate and time the events, and so you can say these are no longer reactions, but actions.

In the git context, where you typed something wrong, the lines are blurred, you're processing while you're acting, you're typing while you're evaluating what you're typing, first line of defence is you're feeling/sensing that you typed wrong, either from the feedback that your fingers touched too many keys, or that you felt the rhythm of your typing was wrong, at least for me, this happens way faster than my visual input. I'm making errors as I type this, and they're corrected faster than I can really read it, sometimes I get it wrong and deleted a word that was correct. But still, watching people type, I see this all the time, they're not watching and thinking about the letters exclusively, there's something going on in their minds at the same time. 100 ms is a rather wide window in this context.

Also, that said, we did a lot of experiments at work with a reaction time tester, most people got less than 70 ms after practice (a led lights up at a random interval between 2 and 10 seconds)

Re: Why is Git Autocorrect too fast for Formula One drivers?

#149
post #74
post #44

Earlier quoted context omitted.

> you can absolutely ctrl+c before 100 more ms are up Not gonna believe that without empirical evidence.

I am not sure, have you read it properly? The scenario is that you are pushing enter, halfway change your mind, and your are switching to ctrl+c. So it is not a reaction time, but an enter to ctrl+c scenario. Regarding reaction time, below 120ms (on a computer, in a browser(!)) is consistently achievable, e.g. this random yt video https://youtu.be/EH0Kh7WQM7w?t=45 . For some reason, I can't find more official reactio…

That scenario seems to me fishy to begin with, is that something that actually happens, or just something people imagine? How would it work that you "change your mind halfway through" and somehow cannot stop your finger from pressing enter, but can move them over and hit ctrl-c in a ridiculously short time window?

> So it is not a reaction time, but an enter to ctrl+c scenario.

At minimum, if we ignore the whole "changing your mind" thing. And for comparison: the world record for typing speed (over 15 seconds and without using any modifier keys) is around 300wpm, which translates to one keypress every 40ms - you really think 100ms to press two keys is something "you can absolutely" do? I'd believe that some* people could sometimes do it, but certainly not just anyone.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#150

> 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.

I run a wordle spinoff, xordle, which involves two wordle puzzles on one board. This means you can guess a word and get all 5 letters green, but it isn't either of the target words. When you do this it just says "Huh?" on the right. People love that bit.

Can confirm. I loved that bit.
Post reply on HN