Re: Git branch outputs usage message on stderr

From: Jeff King <peff@peff.net>
Date: Jan 16, 2025, 10:24 UTC
Message-ID: <20250116102426.GA773990@coredump.intra.peff.net>
In-Reply-To: <xmqqplknvek2.fsf@gitster.g>

On Wed, Jan 15, 2025 at 03:32:29PM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> Jeff King <peff@peff.net> 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. ;)

Show 7 quoted lines

> 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.

Show 8 quoted lines

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