From: Jeff King <peff@peff.net>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: git@vger.kernel.org
Subject: [PATCH 1/2] revision: avoid reporting known options as unknown on error
Date: Fri, 25 Sep 2026 16:35:48 -0400 [thread overview]
Message-ID: <20260925203548.GA1544493@coredump.intra.peff.net> (raw)
In-Reply-To: <20260925203359.GA1506705@coredump.intra.peff.net>
In parse_revision_opt(), we report "unknown option" when
handle_revision_opt() returns a negative value or zero. But these are
two different conditions: a negative value indicates a malformed option
(like a missing argument) and zero indicates an unknown option.
So malformed options produce nonsense like this:
$ git shortlog --default
error: bad --default argument
error: unknown option `--default'
usage: [...]
We should treat a negative return as a logic error which has already
been reported by handle_revision_opt(), and just show the regular usage
message.
Signed-off-by: Jeff King <peff@peff.net>
---
There's obviously a way to write this that makes the diff a little
shorter and doesn't repeat the usage_with_options() line. I think the
if/else cascade makes the mental model more clear, though.
revision.c | 5 ++++-
t/t4201-shortlog.sh | 6 ++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index ee1df92d1d..f958d8c301 100644
--- a/revision.c
+++ b/revision.c
@@ -2771,7 +2771,10 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
{
int n = handle_revision_opt(revs, ctx->argc, ctx->argv,
&ctx->cpidx, ctx->out, NULL);
- if (n <= 0) {
+ if (n < 0) {
+ /* handle_revision_opt() has already reported the error. */
+ usage_with_options(usagestr, options);
+ } else if (!n) {
error("unknown option `%s'", ctx->argv[0]);
usage_with_options(usagestr, options);
}
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 023fbff546..4ba7f5aec6 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -436,4 +436,10 @@ test_expect_success 'stdin with multiple groups reports error' '
test_must_fail git shortlog --group=author --group=committer <log
'
+test_expect_success 'invalid revision options are not reported as unknown' '
+ test_must_fail git shortlog --default 2>err &&
+ test_grep "bad --default argument" err &&
+ test_grep ! "unknown option" err
+'
+
test_done
--
2.56.0.rc2.289.g137cf50cac
next prev parent reply other threads:[~2026-09-25 20:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 0:28 [BUG] revision: premature free-and-null causes “unknown option `(null)`” Kristoffer Haugsbakk
2026-09-25 8:26 ` Jeff King
2026-09-25 20:33 ` [PATCH 0/2] some parse_revision_opt() bugfixes Jeff King
2026-09-25 20:35 ` Jeff King [this message]
2026-09-25 20:39 ` [PATCH 2/2] revision: handle argv movement in parse_revision_opt() Jeff King
2026-09-26 9:00 ` Kristoffer Haugsbakk
2026-09-28 3:25 ` Jeff King
2026-09-29 7:43 ` Kristoffer Haugsbakk
2026-09-25 22:23 ` [PATCH 0/2] some parse_revision_opt() bugfixes 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=20260925203548.GA1544493@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox