On 2021-04-20 at 19:49:41, Junio C Hamano wrote:
> "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > From: Han-Wen Nienhuys <hanwen@google.com>
> >
> > 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@google.com>
> > ---
> >  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