On Thu, Feb 23, 2023 at 04:45:40PM +0100, Omar Polo wrote:
> I'm proposing to a set of functions to abstract over SHA1Init,
> SHA1Update, SHA1Final and their SHA256 corrispondent.  They follow
> closely the SHA1{Init,Update,Final} interface, to make the switch
> easier.  Since most of the times we're interested to build an object
> id with the resulting digest, got_hash_final_object_id() is provided
> to aid with that.  (It's another bit that will help when the struct
> got_object_id will grow.)
> 
> Diff below expands inflate.c/deflate.c to optionally use this "hash
> context" too, without dropping the SHA1 stuff, but replace all the
> other SHA1*() usage.  Dropping the sha1 bits from inflate/deflate will
> be done as a separate follow-up diff.
> 
> At the moment this should be a no-op in practice, since GOT_HASH_SHA1
> is hardcoded everywhere, but soon we'll start to 'bubble up' the
> digest type, making most of this working transparently on both sha1
> and sha256 repos.
> 
> Note that while my immediate interest is to getting object/packfiles
> parsing working (i.e. only handling bare repos for reading, not
> writing) this should also help for future work on sha256 object
> creation, pack generation, and maybe even for gotd :)
> 
> In the future we might want to expand these API to compute multiple
> digests at the same time (could be required to fetch/send from sha1 to
> sha256 or vice-versa), but it's something so down in the list that is
> not yet implemented to keep these functions small and easy.
> 
> Tests are still fully parsing (without packing, with GOT_TEST_PACK=1,
> and GOT_TEST_PACK=ref-delta.  gotd tests are also fine.)
> 
> comments/ok?  suggestion for alternate naming?

Thanks! This gets quite a lot of housekeeping done.

Given that tests are passing I think you should go ahead with this.
I didn't spot any mistakes reading through, and I like the names
you have chosen.