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

101–110 of 248 posts

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

#101

Post by grayhatter »

jsjshsbd wrote: post #36
SOLAR_FIELDS wrote: post #22

Earlier quoted context omitted.

100 ms is an insanely short window. I would say usually even 1000ms would be too short for me to recognize and kill the command, even if I realized immediately that I had done something wrong.

It's much too short to read an output, interpret it and realize you have to interrupt But often you type something, realize it's wrong while you are typing but not fast enough to stop your hand from pressing [Enter] That is one of the only situation 100ms would be enough to safe you That being said, the reason in the article for 100ms is just confused commander. Why would anyone: 1) encode a Boolean value as 0/1 in a…

laziness is a virtue of a good programmer.

why demand many char when few char do trick?

also

> Why would anyone [...] encode a duration as a numeric value without unit in a human readable configuration

If I'm only implementing support for a single unit, why would you expect or want to provide a unit? What's the behavior when you provide a unit instead of a number?

> but not doing that extra work is lazy

no, because while I'm not implementing unit parsing for a feature I wouldn't use, instead I'm spending that time implementing a better, faster diff algorithm. Or implementing a new protocol with better security, or sleeping. It's not lazy to do something important instead of something irrelevant. And given we're talking about git, which is already very impressive software, provided for free by volunteers, I'm going to default to assuming they're not just lazy.

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

#102

Post by furyofantares »

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.

I run a wordle spinoff, xordle, which involves two wordle puzzles on one board. This means you can guess a word and get all 5 letters green, but it isn't either of the target words. When you do this it just says "Huh?" on the right. People love that bit.

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

#103

Post by grayhatter »

skykooler wrote: post #83
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".

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

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

#104

Post by p_l »

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.

/bin/ed did in fact evolve on very slow teletypes that used roll paper.

It made the option to print file content with line numbers very useful (personally only used very dumb terminals instead of physical teletype, but experience is a bit similar just with shorter scrollback :D)

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

#105

Post by physicles »

yencabulator wrote: post #91
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 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.

That’s not automatically bad. There are two kinds of Hungarian notation: systems Hungarian, which duplicates information that the type system should be tracking; and apps Hungarian, which encodes information you’d express in types if your language’s type system were expressive enough. [1] goes into the difference.

[1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

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

#106

Post by thedufer »

> Now, why Junio thought deciseconds was a reasonable unit of time measurement for this is never discussed, so I don't really know why that is.

xmobar uses deciseconds in a similar, albeit more problematic place - to declare how often to refresh each section. Using deciseconds is fantastic if your goal is for example configs to have numbers small enough that they clearly can't be milliseconds, resulting in people making the reasonable assumption that it must thus be seconds, and running their commands 10 times as often as they intended to. I've seen a number of accidental load spikes originating from this issue.

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

#109

Post by physicles »

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…

Right, your type system can quickly become unwieldy if you try to create a new type for every slight semantic difference.

I feel like Go strikes a good balance here with the time.Duration type, which I use wherever I can (my _msec example came from C). Go doesn’t allow implicit conversion between types defined with a typedef, so your code ends up being very explicit about what’s going on.

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

#110

Post by yencabulator »

physicles wrote: post #105
yencabulator wrote: post #91

Earlier quoted context omitted.

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.

That’s not automatically bad. There are two kinds of Hungarian notation: systems Hungarian, which duplicates information that the type system should be tracking; and apps Hungarian, which encodes information you’d express in types if your language’s type system were expressive enough. [1] goes into the difference. [1] https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

And this is exactly the kind the language should have a type for, Duration.
Post reply on HN