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

111–120 of 248 posts

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

#111

Post by snvzz »

ninjamuffin99 wrote: post #92
snvzz wrote: 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 fra…

>6 frames is not enough

git good.

(the parent post was a set up for this)

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

#112

Post by iab »

snet0 wrote: post #56
iab wrote: post #48

Earlier quoted context omitted.

“Design” to me intimates an intentional broad-context plan. This is no design, but an organic offshoot

Someone thought of a feature (i.e. configurable autocorrect confirmation delay) and decided the interface should be identical to an existing feature (i.e. whether autocorrect is enabled). In my thinking, that second part is "design" of the interface.

I think that is something that arose from happenstance, not thoughtful intent - this is true because of how confusing the end result is.

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

#113

Post by chuckadams »

vunderba wrote: post #100
WalterBright wrote: post #66

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

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 versions of Bill Gates's BASIC did something similar.

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

#114

Post by benatkin »

NoPicklez wrote: post #108

Cool but I don't know why it needs to be justified that it's too fast even for an F1 driver. Why can't we just say its too fast without all the fluff about being a race car driver, the guy isn't even an F1 driver but Le Mans.

The author is someone who went to conferences that DHH also attended, so for some of the audience it's a funny anecdote.

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

#115

Post by JBiserkov »

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.

NO is the country code for Norway.

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

#116

Post by teraflop »

ekidd wrote: post #98
nikau wrote: 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.

https://www.gnu.org/fun/jokes/ed-msg.en.html

"Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity."

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

#117

Post by Pxtl »

grayhatter wrote: post #103
skykooler wrote: post #83

Earlier quoted context omitted.

I spent a while debugging a library with a chunk_time_ms parameter where it turned out "ms" stood for "microseconds".

I have a very hard time relating to everyone else complaining about ~~lack of units~~ being unable to read/remember API docs. But using `chunk_time_ms` where ms is MICROseconds?! That's unforgivable, and I hope for all our sakes, you don't have to use that lib anymore! :D

The sheer number of APIs of modern coding is exhausting, I can't imagine either trying to keep all the stuff I'm using in my head or having to go back to the docs every time instead of being able to just read the code.

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

#118

Post by zxvkhkxvdvbdxz »

jonas21 wrote: post #93
cobbal wrote: post #80

Earlier quoted context omitted.

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?

Sure, yes. But for human consumption, decisecond is something one can relate to.

I mean, you probably cannot sense the difference in duration between 20 and 30 ms without special equipment.

But you can possibly sense the difference between 2 and 3 deciseconds (200 ms and 300 ms) after some practice.

I think the issue in this case was rather the retrofitting a boolean setting into a numerical setting.

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

#119

Post by theamk »

TeMPOraL wrote: post #95
physicles wrote: post #89

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…

It should not matter though, because std::chrono is not int-convertible - so is it "milliseconds" or "microseconds" or whatever is an minor implementation detail.

You cannot compile FooBar(5000), so there is never confusion in C++ like C has. You have to do explicit "FooBar(std::chrono::milliseconds(500))" or "FooBar(500ms)" if you have literals enabled. And this will handle conversion if needed - you can always do FooBar(500ms) and it will work even if actual type in microseconds.

Similarly, your "auto" example will only compile if gl_timeout is a compatible type, so you don't have to worry about units at all when all your intervals are using std::chrono.

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

#120

Post by stouset »

Dylan16807 wrote: post #84
stouset wrote: post #81

Earlier quoted context omitted.

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.

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