Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

91–100 of 248 posts

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

#91

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 do that, but I can't help thinking that it smells like Hungarian notation.

The best alternative I've found is to accept units in the values, "5 seconds" or "5s". Then just "1" is an incorrect value.

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

#92
post #88

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.

6 frames is not enough to realize you made a typo / read whatever git is outputting telling you that you made a typo, and then respond to that input correctly.

in video games it may seem like a lot of time for a reaction, but a lot of that “reaction time” is based off previous context of the game, visuals and muscle memory and whatnot. If playing street fighter and say youre trying to parry an attack that has a 6 frame startup, you’re already anticipating an attack to “react” to before their attack even starts. When typing git commands, you will never be on that type of alert to anticipate your typos.

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

#93
post #80

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.

It's a decent, if uncommon, unit for human reactions. The difference between 0 and 1 seconds is a noticeably long time to wait for something, but the difference between n and n+1 milliseconds is too fine to be useful.

Milliseconds are a commonly-used unit. It doesn't really matter if 1 ms is too fine a granularity -- you'll just have to write "autocorrect = 500" in your config file instead of "autocorrect = 5", but who cares?

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

#94

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.

About 2, well, you are the actual polluter, even if you just scroll back in history andnuse the same last wrong command because it works anyway.

Well to put it into context, I use fish shell, which will only save commands that have an exit code of 0. By using git autocorrect, I have guaranteed that all git commands have an exit code of 0 :)

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

#95

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

Same here. I'm still torn when this gets pushed into the type system, but my general rule of thumb in C++ context is:

  void FooBar(std::chrono::milliseconds timeout);
is OK, because that's a function signature and you'll see the type when you're looking at it, but with variables, `timeout` is not OK, as 99% of the time you'll see it used like:

  auto timeout = gl_timeout; // or GetTimeoutFromSomewhere().
  FooBar(timeout);
Common use of `auto` in C++ makes it a PITA to trace down exact type when it matters.

(Yes, I use IDE or a language-server-enabled editor when working with C++, and no, I don't have time to stop every 5 seconds to hover my mouse over random symbols to reveal their types.)

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

#96
post #80

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.

It's a decent, if uncommon, unit for human reactions. The difference between 0 and 1 seconds is a noticeably long time to wait for something, but the difference between n and n+1 milliseconds is too fine to be useful.

But the consumers of the API aren't humans, they're programmers.

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

#97

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.

About 2, well, you are the actual polluter, even if you just scroll back in history andnuse the same last wrong command because it works anyway.

The issue is if you accept the wrong command instead of retyping it correctly, you never get the correctly spelled command into your history — and even worse, you don't get it to be more recent than the mistyped command.

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

#98
post #78

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

How wasteful, ed uses just ? for all errors, a 3x saving

Ed also uses "?" for "Are you sure?" If you're sure, you can type the last command a second time to confirm.

The story goes that ed was designed for running over a slow remote connection where output was printed on paper, and the keyboard required very firm presses to generate a signal. Whether this is true or folklore, it would explain a lot.

GNU Ed actually has optional error messages for humans, because why not.

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

#99

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…

For whatever it's worth*: I'm not skeptical of it at all. I've done this in a terminal before without even looking at the screen, so I know it can't have anything to do with visual reaction.

Similar to the other reply, I also commonly do that when typing, where I know I've fat fingered a word, exclusively from the feeling of the keyboard.

But also, your not just trying to beat the fork/exec. You can also successfully beat any number of things. The pre-commit hook, the DNS look up, the TLS handshake. adding an additional 100ms of latency to that could easily be the difference between preempting some action, interrupting it or noticing after it was completed.

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

#100

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

> EH?

I feel like that would also make a good response from the text parser in an old-school interactive fiction game.

Slightly related, but I remember some older variants of BASIC using "?" to represent the PRINT statement - though I think it was less about memory and more just to save time for the programmer typing in the REPL.

Post reply on HN