From: Jeff King <peff@peff.net>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: git@vger.kernel.org
Subject: Re: [BUG] revision: premature free-and-null causes “unknown option `(null)`”
Date: Fri, 25 Sep 2026 04:26:36 -0400 [thread overview]
Message-ID: <20260925082636.GA1493716@coredump.intra.peff.net> (raw)
In-Reply-To: <74796901-ffb1-4cf3-bd63-7294328f70bc@app.fastmail.com>
On Fri, Sep 25, 2026 at 02:28:57AM +0200, Kristoffer Haugsbakk wrote:
> git shortlog -n --not-an-option master
> [...]
>
> I expected it to print the option in quotes. Instead it printed `(null)`
> which I think is the placeholder for when the `%s` arg is `NULL`.
> [...]
>
> I have bisected this to cd439487 (revision: manage memory ownership of
> argv in setup_revisions(), 2025-09-19).
Yep, definitely my fault. I don't have time to do a full write-up now,
but the most direct solution is:
diff --git a/revision.c b/revision.c
index ee1df92d1d..501a4ba36e 100644
--- a/revision.c
+++ b/revision.c
@@ -2768,13 +2768,13 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
const struct option *options,
const char * const usagestr[])
{
int n = handle_revision_opt(revs, ctx->argc, ctx->argv,
&ctx->cpidx, ctx->out, NULL);
if (n <= 0) {
- error("unknown option `%s'", ctx->argv[0]);
+ error("unknown option `%s'", ctx->out[ctx->cpidx - 1]);
usage_with_options(usagestr, options);
}
ctx->argv += n;
ctx->argc -= n;
}
But I think instead doing this:
diff --git a/revision.c b/revision.c
index ee1df92d1d..7b858d54c1 100644
--- a/revision.c
+++ b/revision.c
@@ -2340,7 +2340,8 @@ static void overwrite_argv(int *argc, const char **argv,
if (*value != argv[*argc]) {
mark_argv_for_free(opt, revs, argv[*argc]);
argv[*argc] = *value;
- *value = NULL;
+ if (opt && opt->free_removed_argv_elements)
+ *value = NULL;
}
(*argc)++;
}
will restore some of the hidden assumptions made by pre-cd439487 code.
So it would fix this case, along with any other lurkers.
I know that's probably quite opaque. ;) I'll fully explain what's going
on in a follow-up tomorrow, but I wanted to post the solution quickly so
nobody else wasted time digging.
Thanks for a clear report.
-Peff
next prev parent reply other threads:[~2026-09-25 8:26 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 [this message]
2026-09-25 20:33 ` [PATCH 0/2] some parse_revision_opt() bugfixes Jeff King
2026-09-25 20:35 ` [PATCH 1/2] revision: avoid reporting known options as unknown on error Jeff King
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=20260925082636.GA1493716@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