Re: [PATCH v7 04/28] hash.h: provide constants for the hash IDs
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Jul 22, 2021, 08:31 UTC
- Message-ID
- <CAFQ2z_NmYdckEQ2EfJyhvAYznhq7PdTaMxu+i-BatSkskvC-uw@mail.gmail.com>
- In-Reply-To
- <CAFQ2z_NAQ02y1gaTymzi21aHxh+bswvr6ko_Eg=1uuHds4mGyg@mail.gmail.com>
On Wed, Apr 21, 2021 at 11:43 AM Han-Wen Nienhuys <hanwen@google.com> wrote:
Show 19 quoted lines
>
> On Wed, Apr 21, 2021 at 3:04 AM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > > I agree that it makes sense to have symbolic constants defined in
> > > this file. These are values that fit in the ".format_id" member of
> > > "struct git_hash_algo", and it is preferrable to make sure that the
> > > names align (if I were designing in void, I would have called the
> > > member "algo_id" and made the constants GIT_(SHA1|SHA256)_ALGO_ID).
> > >
> > > Brian? What's your preference ("I am fine to store HASH_ID in the
> > > '.format_id' member" is perfectly an acceptable answer).
> >
> > I slightly prefer FORMAT_ID because it's consistent (and for that reason
> > only), but if HASH_ID is more convenient, that's fine; I don't have a
> > strong opinion at all. Definitely don't reroll the series because of my
> > slight preference. Either way, I think these are fine things to have as
> > constants, and I appreciate you hoisting the comments here.
>
> Either way is fine for me. I can paint the bikeshed in your favorite color :)This is now the first commit of the reftable series. I think it could graduate separately.
-- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado