On Wed, Mar 02 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > [...] >> So the performance cost is trivial & not worth worrying about. > > I already said I am not worried about it, didn't I? These numbers > do not matter in this discussion. Sorry, but I really don't see the point then. You'd like to keep "git rev-parse --parseopt", but now if you feed bad input to it you'll get worse error messages from it, and it's not for a performance benefit then why? Why would we have worse error reporting without any upside? Another common case would be locally hacking a command that uses parse_options(), having it do the wrong thing for some cryptic reason we'd catch in parse_options_check(). Then eventually remember to turn on this GIT_TEST_* knob (i.e. if testing via the command-line/debugger instead of the test suite). I for one do that a lot when working on the parse_options()-using commands in-tree, if this land I'll probably remember to add this knob to my .bashrc, but everyone else will find out the hard way...
