git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: Linus Arver <linusa@google.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Patrick Steinhardt <ps@pks.im>,  John Cai <johncai86@gmail.com>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2 2/4] oidset: refactor oidset_insert_from_set()
Date: Wed, 14 Feb 2024 15:33:06 +0100	[thread overview]
Message-ID: <CAP8UFD1aJD5i68ekHuq0UG14X19y=Eo6qKPianF8MKNf6iZ_WQ@mail.gmail.com> (raw)
In-Reply-To: <owlyle7o9iyf.fsf@fine.c.googlers.com>

On Tue, Feb 13, 2024 at 10:02 PM Linus Arver <linusa@google.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > In a following commit, we will need to add all the oids from a set into
> > another set. In "list-objects-filter.c", there is already a static
> > function called add_all() to do that.
>
> Nice find.
>
> > Let's rename this function oidset_insert_from_set() and move it into
> > oidset.{c,h} to make it generally available.
>
> At some point (I don't ask for it in this series) we should add unit
> tests for this newly-exposed function. Presumably the stuff around
> object/oid handling is stable enough to receive unit tests.

Yeah, ideally there should be unit tests for oidset and all its
features, but it seems to me that there aren't any. Also oidset is
based on khash.h which was originally imported from
https://github.com/attractivechaos/klib/ without tests. So I think
it's a different topic to add tests from scratch to oidset, khash.h or
both.

Actually after taking another look, it looks like khash.h or some of
its features are tested through "helper/test-oidmap.c" and
"t0016-oidmap.sh". I still think it's another topic to test oidset.

> > +void oidset_insert_from_set(struct oidset *dest, struct oidset *src)
> > +{
> > +     struct oidset_iter iter;
> > +     struct object_id *src_oid;
> > +
> > +     oidset_iter_init(src, &iter);
> > +     while ((src_oid = oidset_iter_next(&iter)))
>
> Are the extra parentheses necessary?

Yes. Without them gcc errors out with:

oidset.c: In function ‘oidset_insert_from_set’:
oidset.c:32:16: error: suggest parentheses around assignment used as
truth value [-Werror=parentheses]
  32 |         while (src_oid = oidset_iter_next(&iter))
     |                ^~~~~~~

Having extra parentheses is a way to tell the compiler that we do want
to use '=' and not '=='. This helps avoid the very common mistake of
using '=' where '==' was intended.

> > +/**
> > + * Insert all the oids that are in set 'src' into set 'dest'; a copy
> > + * is made of each oid inserted into set 'dest'.
> > + */
>
> Just above in oid_insert() there is already a comment about needing to
> copy each oid.

(It's "oidset_insert()" not "oid_insert()".)

>     /**
>      * Insert the oid into the set; a copy is made, so "oid" does not need
>      * to persist after this function is called.
>      *
>      * Returns 1 if the oid was already in the set, 0 otherwise. This can be used
>      * to perform an efficient check-and-add.
>      */
>
> so perhaps the following wording is simpler?
>
>     Like oid_insert(), but insert all oids found in 'src'. Calls
>     oid_insert() internally.

(What you suggest would need s/oid_insert/oidset_insert/)

Yeah, it's a bit simpler and shorter, but on the other hand a reader
might have to read both this and the oidset_insert() doc, so in the
end I am not sure it's a big win for readability. And if they don't
read the oidset_insert() doc, they might miss the fact that we are
copying the oids we insert, which might result in a bug.

Also your wording ties the implementation with oidset_insert(), which
we might not want if we could find something more performant. See
Junio's comment on this patch saying his initial reaction was that
copying underlying bits may even be more efficient.

So I prefer not to change this.

> > +void oidset_insert_from_set(struct oidset *dest, struct oidset *src);
>
> Perhaps "oidset_insert_all" would be a simpler name? I generally prefer
> to reuse any descriptors in comments to guide the names. Plus this
> function used to be called "add_all()" so keeping the "all" naming style
> feels right.

We already have other related types like 'struct oid-array' and
'struct oidmap' to store oids, as well as code that inserts many oids
into an oidset from a 'struct ref *' linked list or array in a tight
loop. So if we want to add functions inserting all the oids from
instances of such types, how should we call them?

I would say we should use suffixes like: "_from_set", "_from_map",
"from_array", "_from_ref_list", "_from_ref_array", etc.

If we start using just "_all" for oidset, then what should we use for
the other types? I don't see a good answer to that, so I prefer to
stick with "_from_set" for oidset.

Thanks.


  reply	other threads:[~2024-02-14 14:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 13:50 [PATCH v2 0/4] rev-list: allow missing tips with --missing Christian Couder
2024-02-08 13:50 ` [PATCH v2 1/4] revision: clarify a 'return NULL' in get_reference() Christian Couder
2024-02-08 13:50 ` [PATCH v2 2/4] oidset: refactor oidset_insert_from_set() Christian Couder
2024-02-08 17:33   ` Junio C Hamano
2024-02-13 21:02   ` Linus Arver
2024-02-14 14:33     ` Christian Couder [this message]
2024-02-16  1:10       ` Linus Arver
2024-02-16 10:38         ` Christian Couder
2024-02-16 20:27           ` Linus Arver
2024-02-08 13:50 ` [PATCH v2 3/4] t6022: fix 'test' style and 'even though' typo Christian Couder
2024-02-08 13:50 ` [PATCH v2 4/4] rev-list: allow missing tips with --missing=[print|allow*] Christian Couder
2024-02-08 17:44   ` Junio C Hamano
2024-02-13 22:38     ` Linus Arver
2024-02-14 14:34       ` Christian Couder
2024-02-14 16:49         ` Junio C Hamano
2024-02-14 14:39     ` Christian Couder
2024-02-13 22:33   ` Linus Arver
2024-02-14 14:38     ` Christian Couder
2024-02-16  1:24       ` Linus Arver
2024-02-08 23:15 ` [PATCH v2 0/4] rev-list: allow missing tips with --missing Junio C Hamano
2024-02-14 14:26   ` Christian Couder
2024-02-14 14:25 ` [PATCH v3 0/5] " Christian Couder
2024-02-14 14:25   ` [PATCH v3 1/5] t9210: do not rely on lazy fetching to fail Christian Couder
2024-02-14 14:25   ` [PATCH v3 2/5] revision: clarify a 'return NULL' in get_reference() Christian Couder
2024-02-14 14:25   ` [PATCH v3 3/5] oidset: refactor oidset_insert_from_set() Christian Couder
2024-02-14 14:25   ` [PATCH v3 4/5] t6022: fix 'test' style and 'even though' typo Christian Couder
2024-02-14 14:25   ` [PATCH v3 5/5] rev-list: allow missing tips with --missing=[print|allow*] Christian Couder
2024-02-16 21:56   ` [PATCH v3 0/5] rev-list: allow missing tips with --missing Linus Arver
2024-02-28  9:10   ` [PATCH] revision: fix --missing=[print|allow*] for annotated tags Christian Couder
2024-02-28 17:46     ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP8UFD1aJD5i68ekHuq0UG14X19y=Eo6qKPianF8MKNf6iZ_WQ@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johncai86@gmail.com \
    --cc=linusa@google.com \
    --cc=ps@pks.im \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).