"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).
Thanks.
