From: Christian Couder <christian.couder@gmail.com>
To: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] unit-tests: convert t/helper/test-oid-array.c to unit-tests
Date: Tue, 27 Feb 2024 10:59:06 +0100 [thread overview]
Message-ID: <CAP8UFD0yOXPyTvRCXxhoWXASW+HP230jVMCDzipg5PLAyVXJUA@mail.gmail.com> (raw)
In-Reply-To: <CZF8YROS9RVC.9H2EKYCF08VK@gmail.com>
On Mon, Feb 26, 2024 at 8:11 PM Ghanshyam Thakkar
<shyamthakkar001@gmail.com> wrote:
>
> On Mon Feb 26, 2024 at 8:41 PM IST, Christian Couder wrote:
> > So I think it would be better to work on other things instead, like
> > perhaps reviewing other people's work or working on other bug fixes or
> > features. Anyway now that this is on the mailing list, I might as well
> > review it as it could help with your application. But please consider
> > working on other things.
>
> I understand and will work on other things.
Thanks!
> > > In unit testing however, we do not
> > > need to initialize the repo. We can set the length of the hexadecimal
> > > strbuf according to the algorithm used directly.
> >
> > So is your patch doing that or not? It might be better to be explicit.
> > Also if 'strbuf's are used, then is it really worth it to set their
> > length in advance, instead of just letting them grow to the right
> > length as we add hex to them?
>
> I thought of it like this: If we were to just let them grow, then we
> would need separate logic for reusing that strbuf or use a different
> one everytime since it always grows. By separating allocation
> (hex_strbuf_init) and manipulation (fill_hex_strbuf), that same strbuf
> can be reused for different hex values.
>
> But, none of the test currently need to reuse the same strbuf, so I
> suppose it is better to just let it grow and even if the need arises we
> can use strbuf_splice().
It's not a problem to use a new strbuf for each different hex value.
Tests don't need a lot of performance as they are used mostly by
developers, not by everyone using Git. Also if you want to reuse a
strbuf, you can just use strbuf_reset() on it and then reuse it.
prev parent reply other threads:[~2024-02-27 9:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 19:32 [PATCH] unit-tests: convert t/helper/test-oid-array.c to unit-tests Ghanshyam Thakkar
2024-02-23 19:37 ` Ghanshyam Thakkar
2024-02-26 15:11 ` Christian Couder
2024-02-26 19:11 ` Ghanshyam Thakkar
2024-02-27 9:59 ` Christian Couder [this message]
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=CAP8UFD0yOXPyTvRCXxhoWXASW+HP230jVMCDzipg5PLAyVXJUA@mail.gmail.com \
--to=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=shyamthakkar001@gmail.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;
as well as URLs for NNTP newsgroup(s).