Re: Git branch outputs usage message on stderr

From: Jeff King <peff@peff.net>
Date: Jan 15, 2025, 21:29 UTC
Message-ID: <20250115212952.GA96537@coredump.intra.peff.net>
In-Reply-To: <xmqqa5brydz1.fsf@gitster.g>

On Wed, Jan 15, 2025 at 01:16:50PM -0800, Junio C Hamano wrote:

Show 7 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Yeah, I agree it is funny to have a "maybe noop, maybe exit" function.
> > Perhaps a different name would help? I'd expect show_usage_help() to
> > always do what the name says. Maybe check_help_option() or something?
> 
> maybe_show_usage_help()?

Heh, I almost suggested that one, too, but worried it was too clunky. But maybe since we both thought of it...

Show 11 quoted lines

> > I think parse-options will exit(129) in this case, and that's what t0012
> > insists upon.
> 
> Yeah, but the test can be adjusted to updated reality if needed.  
> 
> In this case, the command is doing what the end-user asked it to do,
> and if we were writing the system from scratch, 0 would certainly be
> the right exit status in this case.  If hit usage_with_options()
> because the command line option supplied by the user was nonsense,
> we should exit with non-zero, but I am not sure if exit(129) is a
> good idea here.

I certainly see an argument for exit(0), but whatever we do should be consistent with how parse-options handles it (since whether we use this or leave it to parse-options is purely an implementation detail that the user should not need to be aware of).

And it uses code 129, even for "-h". I don't see any explicit rationale for that in the history; I think it goes back to the beginning of parse-options. It happens via the PARSE_OPT_HELP flag, but curiously we also trigger that for ambiguous options (which should exit with error). That might be a bug-in-waiting if we start handling PARSE_OPT_HELP differently.

-Peff