Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

Post reply on HN
Print view View original

81–90 of 248 posts

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

#81

Post by stouset »

zX41ZdbW wrote: post #71

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

The “real” issue is an untyped configuration language which tries to guess at what you actually meant by 1. They’re tripling down on this by making 1 a Boolean true but other integers be deciseconds. This is the same questionable logic behind YAML’s infamous “no” == false.

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

#82

Post by dullcrisp »

orangepanda wrote: post #64
dullcrisp wrote: post #57

Earlier quoted context omitted.

I think if it's spring-loaded then definitely. (But it's 100ms, not 10ms.)

Assuming the best case scenario of feeling the slap in 90ms, it would leave 10ms to abort the command. Or did the 90-180ms range refer to something else?

Oh I see, you’re right.

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

#83

Post by skykooler »

Pxtl wrote: post #30

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 spent a while debugging a library with a chunk_time_ms parameter where it turned out "ms" stood for "microseconds".

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

#84

Post by Dylan16807 »

stouset wrote: post #81
zX41ZdbW wrote: post #71

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

The “real” issue is an untyped configuration language which tries to guess at what you actually meant by 1. They’re tripling down on this by making 1 a Boolean true but other integers be deciseconds. This is the same questionable logic behind YAML’s infamous “no” == false.

I'd say the new addition is more of a special case of rounding than it is messing up types.

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

#85

Post by pc86 »

Etheryte wrote: post #69
shawabawa3 wrote: post #35

Earlier quoted context omitted.

In this case the reaction starts before you hit enter, as you're typing the command So, you type `git pshu ` 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

I'm still pretty skeptical of this claim. If you type 60 wpm, which is faster than an average human, but regular for people who type as professionals, you spend on average 200ms on a keystroke. 60 standard words per minute means 300 chars per minute [0], so 5 chars per second which is 200ms per char. Many people type faster than this, yes, but it's all still very much pushing it just to even meet the 100ms limit, and…

Even if you typed 120 wpm, which is "competitive typing" speed according to this thing[0], it's going to take you 200ms to type ctrl+c, and even if you hit both more-or-less simultaneously you're going to be above the 100ms threshold. So to realistically be able to do something like beat the threshold during normal work and not a speed-centered environment you're probably looking at regularly 160 wpm or more?

I'm not a competitive speed typist or anything but I struggle to get above 110 on a standard keyboard and I don't think I've ever seen anyone above the 125-130 range.

[0] https://www.typingpal.com/en/documentation/school-edition/pe...

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

#86

Post by moffkalast »

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

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

#87

Post by dankwizard »

dusted wrote: 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.

Neo, get off HN and go destroy the agents!

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

#89

Post by physicles »

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.

Post reply on HN