Reading this post, the term "software archeology" and "programmer archeologist" come to mind. (Thank you, Vernor Vinge, for the latter concept.)
I can’t help but feel like you’re calling me “old”…
Not my intention! Just an esteemed git archeologist
Why is Git Autocorrect too fast for Formula One drivers?
41–50 of 248 posts
Re: Why is Git Autocorrect too fast for Formula One drivers?
#42I agree that 'prompt' should be the value to set if you want git autocorrect to work for you. I'd however want that the Y is the default rather than the N, so that a user can just press enter once they've confirmed it. In any case it is not a good idea to have a CLI command happen without your approval, even if the intention was really obvious.
If prompt is the default, mistyped scripts will hang rather than exit 1 if they have stdin open. I think that causes more problems than it solves.
Re: Why is Git Autocorrect too fast for Formula One drivers?
#43Pet 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.
Alternatively, you can also accept the value with a unit and return an error when a plain number is entered (so --timeout 5s or --timeout 5h is valid but --timeout 5 returns an error).
Re: Why is Git Autocorrect too fast for Formula One drivers?
#44Earlier quoted context omitted.
Maybe worth noting here that 100ms is well under the human reaction time. For context, professional sprinters have been measured to have a reaction time in the ballpark of 160ms, for pretty much everyone else it's higher. And this is only for the reaction, you still need to move your hand, press the keys, etc.
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
> you can absolutely ctrl+c before 100 more ms are up
Not gonna believe that without empirical evidence.
Re: Why is Git Autocorrect too fast for Formula One drivers?
#45So Mercurial had something like this back in ancient times, but git devs decided to make a worse implementation.
Re: Why is Git Autocorrect too fast for Formula One drivers?
#46This seems like really quite bad design.
EDIT: 1) is the result of my misreading of the article, the "previous value" never existed in git.
1) Pushing a change that silently break by reinterpreting a previous configuration value (1=true) as a different value (1=0.100ms confirmation delay) should pretty much always be avoided. Obviously you'd want to clear old values if they existed (maybe this did happen? it's unclear to me), but you also probably want to rename the configuration label..
2) Having `help.autocorrect`'s configuration argument be a time, measured in a non-standard (for most users) unit, is just plainly bad. Give me a boolean to enable, and a decimal to control the confirmation time.
Re: Why is Git Autocorrect too fast for Formula One drivers?
#47Pet 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.
Be it seconds or milliseconds, eventually your program evolves to need tenths or less of that unit and you can either support decimal points, create a new field and deprecate the old one, or do a breaking change that makes the poor SOB that needs to validate a breaking change-bearing upgrade in production before turning it on get a migraine if they have to toggle back and forth more than a couple times. Code isn’t always arranged so that a config change and a build/runtime change can be tucked into a single commit that can be applied or rolled back atomically.
All because someone thought surely nobody would ever want something to happen on a quarter of a second delay/interval, or a 250 microsecond one.
Re: Why is Git Autocorrect too fast for Formula One drivers?
#48This seems like really quite bad design. EDIT: 1) is the result of my misreading of the article, the "previous value" never existed in git. 1) Pushing a change that silently break by reinterpreting a previous configuration value (1=true) as a different value (1=0.100ms confirmation delay) should pretty much always be avoided. Obviously you'd want to clear old values if they existed (maybe this did happen? it's unclea…
“Design” to me intimates an intentional broad-context plan. This is no design, but an organic offshoot
Re: Why is Git Autocorrect too fast for Formula One drivers?
#49Reaction times differ by types of stimulus, auditory is slightly faster than visual and tactile slightly faster than that at 90 - 180 ms So if git gave you a slap instead of an error message you might just about have time to react.
The slapping device would need to build inertia for you to feel the slap. Is 10ms enough for that?
Re: Why is Git Autocorrect too fast for Formula One drivers?
#50Yet another example where git shows its lack of user-friendly design
Well it is named after its author after all.