Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

181–190 of 248 posts

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

#181

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

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

JetBrains does a great thing where they show types for a lot of things as labels all the time instead of having to hover over all the things.

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

#182

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…

the zx spectrum did this too, except you could only type the "short forms" (which were always rendered in full). It had keywords on its keys. I.e. to type print, you had to press the "print" key.

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

#183
post #98
post #78

Earlier quoted context omitted.

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.

Here is a good YT channel on such computers and terminals.

Not only story, some of these running resurrected today.

https://youtu.be/zeL3mbq1mEg?si=gUUO_nEsMtcZ5Z_A

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

#184

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…

I just tried it out.

I wrote this bash script:

    #!/usr/bin/env bash
    start_time=$(gdate +%s%3N)
    # Function to handle Ctrl+C (SIGINT)
    on_ctrl_c() {
        end_time=$(gdate +%s%3N)
        total_ms=$((end_time - start_time))
        # Calculate integer seconds and the remaining milliseconds
        seconds=$((total_ms / 1000))
        millis=$((total_ms % 1000))

        # Print the runtime in seconds.milliseconds
        echo "Script ran for ${seconds}.$(printf '%03d' ${millis}) seconds."
        exit 0
    }

    # Trap Ctrl+C (SIGINT) and call on_ctrl_c
    trap on_ctrl_c INT

    # Keep the script running indefinitely
    while true; do
        sleep 1
    done

And then i typed "bash sleep.sh git push origin master"

and got "Script ran for 0.064 seconds."

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

#185

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…

It's almost like Git is a version control system built by developers who only knew Perl and C.

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

#186

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…

Though, ironically, msec is still ambiguous because that could be milli or micro. It's often milli so I wouldn't fault it, but we use micros just enough at my workplace where the distinction matters. I would usually do timeout_micros or timeout_millis.

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

#187
post #173
post #166

Earlier quoted context omitted.

Most probably that was a false start: "World Athletics rules that if an athlete moves within 100 milliseconds (0.1 seconds) of the pistol being fired to start the race, then that constitutes a false start." https://www.nytimes.com/athletic/5678148/2024/08/03/olympics...

That value has also been criticised as too high.

What is the argument for it being too high?

The argument for it being what it is is the fact that our auditorial processing (when using a starter pistol) or visual processing (looking at start-lights) takes time, as well as transferring that message to the relevant muscles. 100 milliseconds is a pretty good average actually

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

#188

Earlier quoted context omitted.

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 :)

wow, our brains work differently, how can you smile in that circumstance? :)

It's a terrible idea of fish not to save errors in history (even if the way bash does it is not optimal, ignoring/obliterating the error return fact) because running a command to look up the state of something can easily return the state you are checking along with an error code. "What was that awesome three letter TLD I looked up yesterday that was available? damn, not a valid domain is an error code" and just like that SEX.COM slips through your grasp, and your only recourse would be to hijack it.

but it's compoundedly worse to feel like the problem is solved by autocorrect further polluting your history.

I would not want to be fixing things downstream of you, where you would be perfectly happy downstream of me.

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

#189

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…

Though, ironically, msec is still ambiguous because that could be milli or micro. It's often milli so I wouldn't fault it, but we use micros just enough at my workplace where the distinction matters. I would usually do timeout_micros or timeout_millis.

can also do usec for micro

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

#190

Earlier quoted context omitted.

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

> 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. JetBrains does a great thing where they show types for a lot of things as labels all the time instead of having to hover over all the things.

Right; the so-called "inlay hints" are also provided by clangd over LSP, so I have them in my Emacs too. Super helpful, but not always there when I need them.
Post reply on HN