Re: [PATCH 01/17] cache: update object ID functions for the_hash_algo
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Jul 9, 2018, 23:26 UTC
- Message-ID
- <20180709232656.GA535220@genre.crustytoothpaste.net>
- In-Reply-To
- <CA+P7+xoMSWfV1ZqokGDvoZVRP65puiiwhTKHbuaiUPS2suA3oQ@mail.gmail.com>
On Sun, Jul 08, 2018 at 09:31:42PM -0700, Jacob Keller wrote:
Show 22 quoted lines
> On Sun, Jul 8, 2018 at 9:05 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
> >
> > On Sun, Jul 8, 2018 at 10:38 PM Jacob Keller <jacob.keller@gmail.com> wrote:
> > > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> > > <sandals@crustytoothpaste.net> wrote:
> > > > static inline int oidcmp(const struct object_id *oid1, const struct object_id *oid2)
> > > > {
> > > > - return hashcmp(oid1->hash, oid2->hash);
> > > > + return memcmp(oid1->hash, oid2->hash, the_hash_algo->rawsz);
> > > > }
> > >
> > > Just curious, what's the reasoning for not using the hashcmp anymore?
> >
> > hashcmp() is specific to SHA-1 (for instance, it hardocdes
> > GIT_SHA1_RAWSZ). oidcmp() is meant as the hash-agnostic replacement
> > for hashcmp(), so it doesn't make sense to continue implementing
> > oidcmp() in terms of hashcmp() (the latter of which will eventually be
> > retired, presumably).
>
> Fair. I just saw that hashcmp was also updated to use the_hash_algo,
> but if we're going to drop it eventually, then there's zero reason to
> keep implementing oidcmp in terms of it, so... makes sense to me!Actually, this reminded me that I have a patch that I had forgotten about in my next series that updates hashcmp. I'll squash that in in my reroll, and undo this change.
As a bonus, it also has a nicer commit message which I will include explaining why this is necessary.
-- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204