All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Brooke Kuhlmann <brooke@alchemists.io>
Subject: Re: [PATCH 3/9] ref-filter: strip signature when parsing tag trailers
Date: Tue, 10 Sep 2024 08:08:55 +0200	[thread overview]
Message-ID: <Zt_id3Fm6IXMhODF@pks.im> (raw)
In-Reply-To: <20240909231445.GC921834@coredump.intra.peff.net>

On Mon, Sep 09, 2024 at 07:14:45PM -0400, Jeff King wrote:
> The implementation here is pretty simple: we just make a NUL-terminated
> copy of the non-signature part of the tag (which we've already parsed)
> and pass it to the trailer API. There are some alternatives I rejected,
> at least for now:
> 
>   - the trailer code already understands skipping past some cruft at the
>     end of a commit, such as patch dividers. see find_end_of_log_message().

s/./,

>     We could teach it to do the same for signatures. But since this is
>     the only context where we'd want that feature, and since we've already
>     parsed the object into subject/body/signature here, it seemed easier
>     to just pass in the truncated message.
> 
>   - it would be nice if we could just pass in a pointer/len pair to the

s/it/It

> diff --git a/ref-filter.c b/ref-filter.c
> index 0f5513ba7e..e39f505a81 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -2008,9 +2008,17 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct exp
>  			v->s = strbuf_detach(&s, NULL);
>  		} else if (atom->u.contents.option == C_TRAILERS) {
>  			struct strbuf s = STRBUF_INIT;
> +			const char *msg;
> +			char *to_free = NULL;
> +
> +			if (siglen)
> +				msg = to_free = xmemdupz(subpos, sigpos - subpos);
> +			else
> +				msg = subpos;
>  
>  			/* Format the trailer info according to the trailer_opts given */
> -			format_trailers_from_commit(&atom->u.contents.trailer_opts, subpos, &s);
> +			format_trailers_from_commit(&atom->u.contents.trailer_opts, msg, &s);
> +			free(to_free);
>  
>  			v->s = strbuf_detach(&s, NULL);
>  		} else if (atom->u.contents.option == C_BARE)

I've been surprised that we use `subpos` as the starting point here,
which includes the whole message including its subject. I would have
thought that it was sufficient to only pass the message body as input,
which saves allocating some bytes. At least `trailer_info_get()` does
not seem to care about the subject at all.

In any case this would be a micro-optimization anyway, it just left me
scratching my head for a second or two.

Patrick

  reply	other threads:[~2024-09-10  6:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-09 23:07 [PATCH 0/9] ref-filter %(trailer) fixes Jeff King
2024-09-09 23:08 ` [PATCH 1/9] t6300: drop newline from wrapped test title Jeff King
2024-09-09 23:12 ` [PATCH 2/9] ref-filter: avoid extra copies of payload/signature Jeff King
2024-09-10  6:09   ` Patrick Steinhardt
2024-09-10  6:26     ` Jeff King
2024-09-09 23:14 ` [PATCH 3/9] ref-filter: strip signature when parsing tag trailers Jeff King
2024-09-10  6:08   ` Patrick Steinhardt [this message]
2024-09-10  6:28     ` Jeff King
2024-09-09 23:14 ` [PATCH 4/9] ref-filter: drop useless cast in trailers_atom_parser() Jeff King
2024-09-09 23:16 ` [PATCH 5/9] ref-filter: store ref_trailer_buf data per-atom Jeff King
2024-09-10  6:08   ` Patrick Steinhardt
2024-09-09 23:18 ` [PATCH 6/9] ref-filter: fix leak of %(trailers) "argbuf" Jeff King
2024-09-10  6:09   ` Patrick Steinhardt
2024-09-10  6:33     ` Jeff King
2024-09-09 23:19 ` [PATCH 7/9] ref-filter: fix leak with %(describe) arguments Jeff King
2024-09-09 23:19 ` [PATCH 8/9] ref-filter: fix leak when formatting %(push:remoteref) Jeff King
2024-09-10  6:09   ` Patrick Steinhardt
2024-09-09 23:21 ` [PATCH 9/9] ref-filter: add ref_format_clear() function Jeff King
2024-09-10  6:09   ` Patrick Steinhardt
2024-09-10  6:37     ` Jeff King
2024-09-10  6:57 ` [PATCH 10/9] ref-filter: fix leak with unterminated %(if) atoms Patrick Steinhardt
2024-09-10  7:12   ` Jeff King
2024-09-10 16:48   ` Junio C Hamano
2024-09-12 10:22     ` Patrick Steinhardt
2024-09-12 11:18       ` Jeff King
2024-09-12 11:32         ` Patrick Steinhardt
2024-09-12 20:24         ` 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=Zt_id3Fm6IXMhODF@pks.im \
    --to=ps@pks.im \
    --cc=brooke@alchemists.io \
    --cc=git@vger.kernel.org \
    --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.