Re: [PATCH] rev-parse: have --parseopt callers exit 0 on --help

[Jeff King <peff@peff.net>]

On Tue, Mar 17, 2026 at 10:55:43AM -0400, Jeff King wrote:

> I agree with the general idea that "-h" usually should exit 0. But this
> is not just a bug fix for --parseopt, but a change in overall intent. It
> might be worth digging in the commit history or list archive to see if
> there's any discussion on why we are using 129 in the first place.

I dug around a little but couldn't find anything conclusive. The first
"129" goes back to 2007:

  https://lore.kernel.org/git/20071013221450.GC2875@steel.home/

But there (and most spots where it is added) it is being used to show
options when we have an unknown option. So I _think_ what mostly
happened is that we show options in two different scenarios: on an
error, and when somebody asks for "-h". And we never differentiated the
two, and the latter just inherited the exit code for the former.

For example, when you look at ff43ec3e2d (parse-opt: create
parse_options_step., 2008-06-23), it introduces:

+       switch (parse_options_step(&ctx, options, usagestr)) {
+       case PARSE_OPT_HELP:
+               exit(129);

and only later did we add PARSE_OPT_ERROR to that switch statement. And
back then, PARSE_OPT_HELP came only from running usage_with_options().

But I couldn't find any discussion or intentional use of 129 for "-h"
output. I do suspect that there may still be some untangling to do. In
the earlier (again, untested) patch I showed, I put an exit(0) for that
PARSE_OPT_HELP case. But it may be that there's more surgery needed to
differentiate "we showed help because of -h" versus "we showed help
because you gave a bogus option".

-Peff