On 2021-04-20 at 19:49:41, Junio C Hamano wrote:
> "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
> >
> > This will simplify referencing them from code that is not deeply integrated with
> > Git, in particular, the reftable library.
> >
> > Signed-off-by: Han-Wen Nienhuys <hanwen@xxxxxxxxxx>
> > ---
> > hash.h | 6 ++++++
> > object-file.c | 6 ++----
> > 2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/hash.h b/hash.h
> > index 3fb0c3d4005a..b17fb2927711 100644
> > --- a/hash.h
> > +++ b/hash.h
> > @@ -161,12 +161,18 @@ static inline int hash_algo_by_ptr(const struct git_hash_algo *p)
> > return p - hash_algos;
> > }
> >
> > +/* "sha1", big-endian */
> > +#define GIT_SHA1_HASH_ID 0x73686131
> > +
> > /* The length in bytes and in hex digits of an object name (SHA-1 value). */
> > #define GIT_SHA1_RAWSZ 20
> > #define GIT_SHA1_HEXSZ (2 * GIT_SHA1_RAWSZ)
> > /* The block size of SHA-1. */
> > #define GIT_SHA1_BLKSZ 64
> >
> > +/* "s256", big-endian */
> > +#define GIT_SHA256_HASH_ID 0x73323536
>
> 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.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
