All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>,  Jeff King <peff@peff.net>
Subject: Re: [PATCH v2 0/4] rev-parse: exit 0 on --help
Date: Wed, 01 Jul 2026 15:06:52 -0700	[thread overview]
Message-ID: <xmqqcxx6mkjn.fsf@gitster.g> (raw)
In-Reply-To: <20260701212442.1430084-1-sandals@crustytoothpaste.net> (brian m. carlson's message of "Wed, 1 Jul 2026 21:24:38 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> The standard philosophy for Unix software when a help option (such as
> --help) is specified is that the software should exit 0, printing the
> help output to standard output, since the standard output is for
> user-requested output and the program performed the requested task
> successfully.  If the user specifies an incorrect option, then the help
> output should be printed to standard error (since the user has made a
> mistake) and it should exit unsuccessfully.

Hmph.

> git rev-parse --parseopt properly directs the output in both of these
> cases, but it currently exits 129 when it receives a --help or -h option
> on the command line, which causes its invoking script to do the same.
> This is not in line with the usual behavior and it causes scripts using
> this command to exit unsuccessfully on --help as well.
>
> This series introduces some changes to distinguish the --help and -h
> options from other cases in which we print help output and adjusts the
> exit code to 0 from those two options.  We continue to exit 129 when the
> options are invalid, which is useful information to have for callers.
> We also make the relevant changes such that `git rev-parse --parseopt`
> does the same thing as long as it is invoked in the way specified in the
> manual page (which a quick GitHub search shows almost everyone does).
>
> One of the patches is rather long because we have many cases in which
> we've hard-coded exit code 129 into our tests.  However, the changes
> there should not be complex, only somewhat tedious to review.

It is borderline for "yes, we all know it is obvious that things
should have worked this way from day one, we regret that it is not
the case, but it has been working differently and users' scripts all
have been working with the current behaviour, and it is likely that
they will all break".

Two big things that make it much less likely, saving grace, are that
this is only about "--help" (which is unlikely to be a part of
end-user script), and this makes the invocation succeed (if we were
changing from exit 0 to exit 129, we would be breaking tons more).

;-)

  parent reply	other threads:[~2026-07-01 22:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-15  0:52 Unexpected exit code for --help with rev-parse --parseopt brian m. carlson
2026-03-15  3:14 ` Jeff King
2026-03-15 16:59   ` brian m. carlson
2026-03-15 18:16     ` Jeff King
2026-03-16 22:07 ` [PATCH] rev-parse: have --parseopt callers exit 0 on --help brian m. carlson
2026-03-17  0:47   ` Junio C Hamano
2026-03-17 11:59     ` brian m. carlson
2026-03-17 14:55       ` Jeff King
2026-03-17 15:07         ` Jeff King
2026-03-17 17:06         ` Junio C Hamano
2026-03-17 18:44           ` Jeff King
2026-03-18  0:24             ` brian m. carlson
2026-03-18  1:22               ` Jeff King
2026-03-18  2:45                 ` Junio C Hamano
2026-07-01 21:24   ` [PATCH v2 0/4] rev-parse: " brian m. carlson
2026-07-01 21:24     ` [PATCH v2 1/4] t1517: skip svn tests if svn is not installed brian m. carlson
2026-07-01 22:10       ` Junio C Hamano
2026-07-01 22:27       ` Junio C Hamano
2026-07-02 14:47         ` [PATCH v2 1/4] t1517: skip svn tests if svn is not installed2sy brian m. carlson
2026-07-02  5:37       ` [PATCH v2 1/4] t1517: skip svn tests if svn is not installed Jeff King
2026-07-03 20:36         ` Junio C Hamano
2026-07-04  4:47           ` Jeff King
2026-07-01 21:24     ` [PATCH v2 2/4] parse-options: add a separate case for help output on error brian m. carlson
2026-07-02  8:38       ` Jeff King
2026-07-01 21:24     ` [PATCH v2 3/4] rev-parse: have --parseopt callers exit 0 on --help brian m. carlson
2026-07-01 22:16       ` Junio C Hamano
2026-07-01 21:24     ` [PATCH v2 4/4] parse-options: exit 0 on -h brian m. carlson
2026-07-01 22:06     ` Junio C Hamano [this message]
2026-07-02  8:45       ` [PATCH v2 0/4] rev-parse: exit 0 on --help Jeff King
2026-07-03 20:38         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqcxx6mkjn.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.