From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] rev-parse: have --parseopt callers exit 0 on --help
Date: Wed, 18 Mar 2026 00:24:38 +0000 [thread overview]
Message-ID: <abnwxmoOw-ZLT858@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <20260317184441.GA574291@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
On 2026-03-17 at 18:44:41, Jeff King wrote:
> So unless somebody can come up with a more compelling example, I don't
> really see much backwards-compatibility risk. But maybe I just lack
> imagination. ;)
The only reason I can imagine intentionally using `-h` in a script is to
find out whether an option is supported. For instance, I have this
alias:
co = "!f() { if git checkout -h | grep -qs recurse-submodules; \
then git checkout --recurse-submodules \"$@\"; \
else git checkout \"$@\" && git sui; \
fi; };f"
(`sui` is `submodule update --init`.)
In most cases, that's going to be upstream of a pipe, so unless you're
using `-o pipefail` (which is only in POSIX in POSIX 1003.1-2024), it's
going to succeed anyway.
I suppose one can also use it to generate a manual page, which manual
page generators do, but that seems silly when Git provides much better
ones unless you desperately need one in a different language for which
Git has translations but no manual page.
None of these seem like they're likely to care about the exit status and
I suspect that if they do, they are probably using `|| true` to ignore
the unexpected 129 exit code.
So I agree that there's unlikely to be any sort of backward
compatibility issues. If the consensus is that this is shipped only in
3.0, then we can do that, but I think many people are not going to care
and those that do will welcome the change, so I'd just rather treat it
as a bug that we fix.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2026-03-18 0:24 UTC|newest]
Thread overview: 14+ 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 [this message]
2026-03-18 1:22 ` Jeff King
2026-03-18 2:45 ` 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=abnwxmoOw-ZLT858@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.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.