From: Junio C Hamano <gitster@pobox.com>
To: kristofferhaugsbakk@fastmail.com
Cc: git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [PATCH 2/2] name-rev: learn --format=<pretty>
Date: Fri, 13 Mar 2026 17:22:13 -0700 [thread overview]
Message-ID: <xmqq8qbvz2dm.fsf@gitster.g> (raw)
In-Reply-To: <name-rev_--format.4af@msgid.xyz> (kristofferhaugsbakk@fastmail.com's message of "Fri, 13 Mar 2026 17:03:38 +0100")
kristofferhaugsbakk@fastmail.com writes:
> diff --git a/Documentation/git-name-rev.adoc b/Documentation/git-name-rev.adoc
> index d4f1c4d5945..8f050cd4763 100644
> --- a/Documentation/git-name-rev.adoc
> +++ b/Documentation/git-name-rev.adoc
> @@ -9,7 +9,7 @@ git-name-rev - Find symbolic names for given revs
> SYNOPSIS
> --------
> [verse]
> -'git name-rev' [--tags] [--refs=<pattern>]
> +'git name-rev' [--tags] [--refs=<pattern>] [--format=<pretty>]
> ( --all | --annotate-stdin | <commit-ish>... )
We acquired a new option. Do we need a matching change to
the contents of name_rev_usage[] array?
> +--format=<pretty>::
> +--no-format::
> + Format revisions instead of outputting symbolic names. The
> + default is `--no-format`.
> ++
> +Implies `--name-only`.
If it is implication, would
git name-rev --format=reference --no-name-only
do what is naturally expected?
> @@ -462,6 +472,25 @@ static const char *get_rev_name(const struct object *o, struct strbuf *buf)
> if (o->type != OBJ_COMMIT)
> return get_exact_ref_match(o);
> c = (const struct commit *) o;
> +
> + if (format_ctx) {
> + strbuf_reset(buf);
> +
> + if (format_ctx->want.notes) {
> + struct strbuf notebuf = STRBUF_INIT;
> +
> + format_display_notes(&c->object.oid, ¬ebuf,
> + get_log_output_encoding(),
> + format_ctx->ctx.fmt == CMIT_FMT_USERFORMAT);
> + format_ctx->ctx.notes_message = strbuf_detach(¬ebuf, NULL);
> + }
> +
> + pretty_print_commit(&format_ctx->ctx, c, buf);
> + free(format_ctx->ctx.notes_message);
Is free() the expected thing to do here, or FREE_AND_NULL()? Unlike
callers like log-tree.c:show_log() where a context is prepared, used
once, and then discarded, format_pp is initialized in cmd_name_rev()
once and then repeatedly used by show_name() potentially multiple
times, so there may be a risk of getting confused by this leftover
non-NULL pointer that points at an already free'd piece of memory.
Or there may not be---I did not check, but you as the author must
have already checked, hence this question.
> + return buf->buf;
> + }
> +
> n = get_commit_rev_name(c);
> if (!n)
> return NULL;
> @@ -479,6 +508,7 @@ static const char *get_rev_name(const struct object *o, struct strbuf *buf)
>
> static void show_name(const struct object *obj,
> const char *caller_name,
> + struct pretty_format *format_ctx,
> int always, int allow_undefined, int name_only)
> {
> const char *name;
> @@ -487,7 +517,7 @@ static void show_name(const struct object *obj,
>
> if (!name_only)
> printf("%s ", caller_name ? caller_name : oid_to_hex(oid));
> - name = get_rev_name(obj, &buf);
> + name = get_rev_name(obj, format_ctx, &buf);
> if (name)
> printf("%s\n", name);
> else if (allow_undefined)
> @@ -507,7 +537,9 @@ static char const * const name_rev_usage[] = {
> NULL
> };
>
> -static void name_rev_line(char *p, struct name_ref_data *data)
> +static void name_rev_line(char *p,
> + struct name_ref_data *data,
> + struct pretty_format *format_ctx)
> {
> struct strbuf buf = STRBUF_INIT;
> int counter = 0;
> @@ -532,7 +564,7 @@ static void name_rev_line(char *p, struct name_ref_data *data)
> struct object *o =
> lookup_object(the_repository, &oid);
> if (o)
> - name = get_rev_name(o, &buf);
> + name = get_rev_name(o, format_ctx, &buf);
> }
> *(p+1) = c;
>
> @@ -567,6 +599,10 @@ int cmd_name_rev(int argc,
> #endif
> int all = 0, annotate_stdin = 0, allow_undefined = 1, always = 0, peel_tag = 0;
> struct name_ref_data data = { 0, 0, STRING_LIST_INIT_NODUP, STRING_LIST_INIT_NODUP };
> + const char *format = NULL;
> + struct rev_info format_rev = REV_INFO_INIT;
> + struct pretty_format *format_ctx = NULL;
> + struct pretty_format format_pp = {0};
Hmph, would we want to use the full init_revisions() instead of
static REV_INFO_INIT that initialises a lot more members of the
struct properly, most importantly the "repo" member that points at
the repostiory to be used?
> + if (format) {
> + struct pretty_print_context ctx = {0};
> + struct userformat_want want = {0};
> +
> + get_commit_format(format, &format_rev);
> + ctx.rev = &format_rev;
> + ctx.fmt = format_rev.commit_format;
> + ctx.abbrev = format_rev.abbrev;
> + ctx.date_mode_explicit = format_rev.date_mode_explicit;
> + ctx.date_mode = format_rev.date_mode;
> + ctx.color = GIT_COLOR_AUTO;
> + format_pp.ctx = ctx;
Why does this code initialize and assign to a on-stack ctx first and
then assign it to format_pp.ctx, instead of working on format_pp.ctx
directly?
> + userformat_find_requirements(format, &want);
> + if (want.notes)
> + load_display_notes(NULL);
> +
> + format_pp.want = want;
> + format_ctx = &format_pp;
> +
> + data.name_only = true;
> + }
> +
next prev parent reply other threads:[~2026-03-14 0:22 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 16:03 [PATCH 0/2] name-rev: learn --format=<pretty> kristofferhaugsbakk
2026-03-13 16:03 ` [PATCH 1/2] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-03-14 0:22 ` Junio C Hamano
2026-03-17 22:10 ` Kristoffer Haugsbakk
2026-03-13 16:03 ` [PATCH 2/2] name-rev: learn --format=<pretty> kristofferhaugsbakk
2026-03-14 0:22 ` Junio C Hamano [this message]
2026-03-17 22:07 ` Kristoffer Haugsbakk
2026-03-18 15:36 ` Kristoffer Haugsbakk
2026-03-20 13:09 ` [PATCH v2 0/2] " kristofferhaugsbakk
2026-03-20 13:09 ` [PATCH v2 1/2] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-03-20 13:09 ` [PATCH v2 2/2] name-rev: learn --format=<pretty> kristofferhaugsbakk
2026-03-20 15:25 ` D. Ben Knoble
2026-03-23 17:34 ` Kristoffer Haugsbakk
2026-04-28 22:25 ` [PATCH v3 0/5] format-rev: introduce builtin for on-demand pretty formatting kristofferhaugsbakk
2026-04-28 22:25 ` [PATCH v3 1/5] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-04-28 22:25 ` [PATCH v3 2/5] name-rev: run clang-format before factoring code kristofferhaugsbakk
2026-04-28 22:25 ` [PATCH v3 3/5] name-rev: factor code for sharing with a new command kristofferhaugsbakk
2026-04-30 13:54 ` Phillip Wood
2026-05-01 17:24 ` kristofferhaugsbakk
2026-05-02 10:00 ` Phillip Wood
2026-05-05 19:21 ` Kristoffer Haugsbakk
2026-04-28 22:25 ` [PATCH v3 4/5] name-rev: make dedicated --annotate-stdin --name-only test kristofferhaugsbakk
2026-04-28 22:25 ` [PATCH v3 5/5] format-rev: introduce builtin for on-demand pretty formatting kristofferhaugsbakk
2026-04-29 13:41 ` Kristoffer Haugsbakk
2026-04-30 6:23 ` Kristoffer Haugsbakk
2026-04-30 9:21 ` Kristoffer Haugsbakk
2026-05-01 10:16 ` Phillip Wood
2026-05-01 18:27 ` kristofferhaugsbakk
2026-05-02 10:00 ` Phillip Wood
2026-05-05 19:27 ` Kristoffer Haugsbakk
2026-05-03 19:19 ` Junio C Hamano
2026-05-07 19:34 ` [PATCH v4 0/5] " kristofferhaugsbakk
2026-05-07 19:34 ` [PATCH v4 1/5] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-05-07 19:34 ` [PATCH v4 2/5] name-rev: run clang-format before factoring code kristofferhaugsbakk
2026-05-07 19:34 ` [PATCH v4 3/5] name-rev: factor code for sharing with a new command kristofferhaugsbakk
2026-05-07 19:34 ` [PATCH v4 4/5] name-rev: make dedicated --annotate-stdin --name-only test kristofferhaugsbakk
2026-05-07 19:34 ` [PATCH v4 5/5] format-rev: introduce builtin for on-demand pretty formatting kristofferhaugsbakk
2026-05-08 13:25 ` Kristoffer Haugsbakk
2026-05-11 13:25 ` Kristoffer Haugsbakk
2026-05-11 15:45 ` [PATCH v5 0/5] " kristofferhaugsbakk
2026-05-11 15:45 ` [PATCH v5 1/5] name-rev: wrap both blocks in braces kristofferhaugsbakk
2026-05-11 15:45 ` [PATCH v5 2/5] name-rev: run clang-format before factoring code kristofferhaugsbakk
2026-05-11 15:45 ` [PATCH v5 3/5] name-rev: factor code for sharing with a new command kristofferhaugsbakk
2026-05-11 15:45 ` [PATCH v5 4/5] name-rev: make dedicated --annotate-stdin --name-only test kristofferhaugsbakk
2026-05-11 15:45 ` [PATCH v5 5/5] format-rev: introduce builtin for on-demand pretty formatting kristofferhaugsbakk
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=xmqq8qbvz2dm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=code@khaugsbakk.name \
--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 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.