On Wed, Jan 15, 2025 at 03:32:29PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I don't know if we'd want something like this on top. If somebody is > > interested in just doing all the conversions in the near-term, we could > > do without the optional flag. > > Ah, you are much more practical than I am ;-) I was wondering if we > want a list of "these commands have already been updated" and behave > differently. Heh, I started writing it that way but then got turned off by how annoying it is to look up in a list of strings in bash. ;) > It is a tangent, but I wonder how many among the 40 really needed to > use usage_with_options() to react to "-h" in the first place. In > other words, these manual checks for "-h" are done only because the > code _wants_ to react to "-h" before it calls parse_options(), but > does everybody who _wants_ to do so really _needs_ to do so? You > already have shown that "gir branch" did not have to, and to me, 40 > among 100+ felt way too many. Yes, I had the same thought. Unfortunately it is a lot of brain-power to examine each one, with relatively little gain. > > - test_grep usage output > > + if test -n "$GIT_TEST_HELP_MUST_BE_STDOUT" > > + then > > + test_must_be_empty err && > > This may be a bit stricter than needed (things other than usage may > need to be spitted out), but it is sufficent to declare that we will > deal with any potential fallout only after it becomes necessary ;-). Yep. I'd hope for the most part that "-h" would spew help and nothing else, but I guess we could get hit with a deprecation notice or something. I agree on crossing that bridge when we come to it. -Peff
