From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Kousik Sanagavarapu <five231003@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] ref-filter: sort numerically when ":size" is used
Date: Fri, 01 Sep 2023 10:59:28 -0700 [thread overview]
Message-ID: <xmqqr0nhpyf3.fsf@gitster.g> (raw)
In-Reply-To: <20230901174540.GB1947546@coredump.intra.peff.net> (Jeff King's message of "Fri, 1 Sep 2023 13:45:40 -0400")
Jeff King <peff@peff.net> writes:
> On Fri, Sep 01, 2023 at 09:43:07AM -0700, Junio C Hamano wrote:
>
>> IOW, when you notice that you need to set, say, u.contents.option of
>> an atom to C_LENGTH, shouldn't you set cmp_type of the atom to
>> FIELD_ULONG, somewhere in contents_atom_parser() and friends, and
>> everything should naturally follow, no?
>
> Yeah, I had the same thought after reading the patch. Unfortunately the
> "type" is used only for comparison, not formatting. So you are still
> stuck setting both v->value and v->s in grab_sub_body_contents(). It
> feels like we could hoist that xstrfmt("%"PRIuMAX) to a higher level as
> a preparatory refactoring. But it's not that big a deal to work around
> it if that turns out to be hard.
Setting of the .value member happens O(N) times for the number of
refs involved, which does not bother me. Do you mean "when we know
we are not sorting with size we should omit parsing the string into
the .value member"? If so, I think that would be nice to have.
>> It seems that support for other cmp_types are incomplete in the
>> current code. There are FIELD_ULONG and FIELD_TIME defined, but
>> they do not appear to be used in any way, so the cmp_ref_sorting()
>> would need to be updated to make it actually pay attention to the
>> cmp_type and perform numeric comparison.
>
> I think they are covered implicitly by the "else" block of the
> conditional that checks for FIELD_STR.
Ah, OK. That needs to be future-proofed to force future developers
who want to add different FIELD_FOO type to look at the comparison
logic. If we want to do so, it should be done as a separate topic
for cleaning-up the mess, not as part of this effort.
> So just this is sufficient to make contents:size work:
>
> diff --git a/ref-filter.c b/ref-filter.c
> index 88b021dd1d..02e3b6ba82 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -583,9 +583,10 @@ static int contents_atom_parser(struct ref_format *format, struct used_atom *ato
> atom->u.contents.option = C_BARE;
> else if (!strcmp(arg, "body"))
> atom->u.contents.option = C_BODY;
> - else if (!strcmp(arg, "size"))
> + else if (!strcmp(arg, "size")) {
> + atom->type = FIELD_ULONG;
> atom->u.contents.option = C_LENGTH;
> - else if (!strcmp(arg, "signature"))
> + } else if (!strcmp(arg, "signature"))
> atom->u.contents.option = C_SIG;
> else if (!strcmp(arg, "subject"))
> atom->u.contents.option = C_SUB;
> @@ -1885,9 +1886,10 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct exp
> v->s = strbuf_detach(&sb, NULL);
> } else if (atom->u.contents.option == C_BODY_DEP)
> v->s = xmemdupz(bodypos, bodylen);
> - else if (atom->u.contents.option == C_LENGTH)
> - v->s = xstrfmt("%"PRIuMAX, (uintmax_t)strlen(subpos));
> - else if (atom->u.contents.option == C_BODY)
> + else if (atom->u.contents.option == C_LENGTH) {
> + v->value = strlen(subpos);
> + v->s = xstrfmt("%"PRIuMAX, v->value);
> + } else if (atom->u.contents.option == C_BODY)
> v->s = xmemdupz(bodypos, nonsiglen);
> else if (atom->u.contents.option == C_SIG)
> v->s = xmemdupz(sigpos, siglen);
Yup, exactly.
Thanks.
next prev parent reply other threads:[~2023-09-01 17:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 14:24 [PATCH] ref-filter: sort numerically when ":size" is used Kousik Sanagavarapu
2023-09-01 16:43 ` Junio C Hamano
2023-09-01 17:45 ` Jeff King
2023-09-01 17:59 ` Junio C Hamano [this message]
2023-09-01 18:32 ` Jeff King
2023-09-01 18:59 ` Kousik Sanagavarapu
2023-09-01 19:16 ` Jeff King
2023-09-01 20:21 ` Junio C Hamano
2023-09-01 20:51 ` Jeff King
2023-09-01 20:04 ` Junio C Hamano
2023-09-01 20:40 ` Jeff King
2023-09-02 9:00 ` [PATCH v2] " Kousik Sanagavarapu
2023-09-02 9:11 ` Kousik Sanagavarapu
2023-09-02 22:19 ` 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=xmqqr0nhpyf3.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=five231003@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).