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

241–248 of 248 posts

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

#241

Post by physicles »

jayd16 wrote: post #213
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…

What would you call the current setting that takes both string enums and deciseconds?

help.autocorrect_enabled_or_accept_after_dsec? A name scary enough to convince anyone who uses it to read the docs.

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

#242

Post by pyuser583 »

legacynl wrote: post #187
arp242 wrote: post #173

Earlier quoted context omitted.

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

Reaction time can vary dramatically.

Someone new to the “gunshot, run” dynamic could take longer, a soldier trained via repetition to react to a gunshot could be shorter, and a veteran with PTSD could be shorter still.

100ms is both too long and too short (or so I’ve heard, I’m not an expert).

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

#243

Post by thaumasiotes »

crazygringo wrote: post #228
yencabulator wrote: post #110

Earlier quoted context omitted.

And this is exactly the kind the language should have a type for, Duration.

Not really. I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. Just like I don't want to have a type for a float that means width, and another type for a float that means height. Putting the unit (as oppose to the data type ) in the variable name is helpful, and is not the same as types. For really complicated stuff like dates, sure ma…

> I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth.

> For really complicated stuff like dates, sure make a type or a class.

Pick one. How are you separating days from dates? Not all days have the same number of seconds.

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

#244

Post by darkwater »

catlifeonmars wrote: post #94
darkwater wrote: post #77

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

TIL. And what about programs that don't have autocorrect? How does Fish handle the "up arrow and fix mistyped command" flow?

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

#245

Post by TeMPOraL »

twic wrote: post #237
TeMPOraL wrote: post #214

Earlier quoted context omitted.

> i also have a method parseDuration which accepts a variety of simple but unambiguous string formats for these, like "10ms", "1s", "2h30m", "1m100us", "0", "inf", etc. I did that too with parsers for configuration files; my rule of thumb is that the unit has to always be visible somewhere anywhere a numeric parameter occurs - in the type, in the name, or in the value. Like e.g.: // in config file: { ..., "timeout":…

Mixed unit durations are in ISO 8601, so the idea has had at least some scrutiny: https://en.wikipedia.org/wiki/ISO_8601#Durations One place i have run into confusion is being able to express a given span of time in multiple ways. 1m30s and 90s are the same length, but are they the same thing? Should we always normalise? If we do, do we normalise upwards or downwards? This hasn't actually been a problem with time, bu…

> Mixed unit durations are in ISO 8601

Don't know why I never noticed it before; thanks for posting this! That does give the idea more weight, so I'll consider mixed-unit durations next time I find myself coding up parsing durations in config files.

> Should we always normalise? If we do, do we normalise upwards or downwards?

I'd say normalize, but on the business side, down to regular units - e.g. the config or UI can keep its "1m30s" or "90s" or even "0.025h", but for processing, this gets casted to seconds or millis or whatever the base unit is. Now, this is easy when we're only reading, but if we need to e.g. modify or regenerate the config from current state, I'd be leaning towards keeping around the original format as well.

> i do similar handling with dates, and it turns out we often want to preserve the distinction between 1y6m and 18m

Can you share specific examples where does this matter, other than keeping the user input in the format it was supplied even underlying data values get regenerated from scratch?

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

#246

Post by ghusbands »

crazygringo wrote: post #228
yencabulator wrote: post #110

Earlier quoted context omitted.

And this is exactly the kind the language should have a type for, Duration.

Not really. I don't want to have a type for an integer in seconds, a type for an integer in minutes, a type for an integer in days, and so forth. Just like I don't want to have a type for a float that means width, and another type for a float that means height. Putting the unit (as oppose to the data type ) in the variable name is helpful, and is not the same as types. For really complicated stuff like dates, sure ma…

You're missing the value of these things in identifying bugs. When you subtract a number of seconds from a temperature, you'll be glad for the compile-time error. There also doesn't have to be a runtime cost, as in C++ (and languages supporting value type instances) they can either be type-erased or cost no more than an integer.

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

#247

Post by bmicraft »

lionkor wrote: post #191
bmicraft wrote: post #129

Earlier quoted context omitted.

If you're going to store that unit in one byte (possible even signed) suddenly deci-seconds start making a lot of sense

Why would you do that?

(Perceived) space efficiency. Many of the things still utilizing deciseconds did so before the turn of the century.

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

#248

Post by bmicraft »

whycome wrote: post #234
physicles wrote: post #131

Earlier quoted context omitted.

> Then you end up with something where you can write "TimoutSec=60" as well as "TimeoutSec=1min" in the case of systemd :) But that's wrong too! If TimeoutSec is an integer, then don't accept "1min". If it's some sort of duration type, then don't call it TimeoutSec -- call it Timeout, and don't accept the value "60".

Can we call this the microwave paradox

What's the connection here to microwaves? I don't get it.
Post reply on HN