Subject: Re: [PATCH 04/10] Use original hash for legacy formats

From: Junio C Hamano <[email-masked]>
Date: Fri, 20 Jun 2025 07:26:37 -0700

"brian m. carlson" <[email-masked]> writes:

> We have a large variety of data formats and protocols where no hash
> algorithm was defined and the default was assumed to always be SHA-1.
> Instead of explicitly stating SHA-1, let's use the constant to represent
> the original hash algorithm (which is still SHA-1) so that it's clear
> for documentary purposes that it's a legacy fallback option and not an
> intentional choice to use SHA-1.
>
> Signed-off-by: brian m. carlson <[email-masked]>
> ---
>  builtin/receive-pack.c | 2 +-
>  bundle.c               | 4 ++--
>  connect.c              | 6 +++---
>  fetch-pack.c           | 2 +-
>  pkt-line.c             | 2 +-
>  remote-curl.c          | 2 +-
>  serve.c                | 2 +-
>  setup.c                | 4 ++--
>  transport.c            | 2 +-
>  9 files changed, 13 insertions(+), 13 deletions(-)

I earlier expressed my puzzlement, but this step shows how
GIT_HASH_ORIGINAL may make sense as a transitional measure, letting
us tell between "This place in the code uses GIT_HASH_SHA1 simply
because we haven't examined and inspected it for the purpose of
allowing us to eventually switch the default" and "This place in the
code we determined need to keep using SHA1 even when the default is
different".

If that is what is going on, after the whole-code transition
finishes, we would want to rename _ORIGINAL back to _SHA1 for
readability, as in such a future, developers should not have to
remember that we originally used SHA-1.

If we call use a name with SHA-1 in it (e.g., GIT_HASH_MUST_BE_SHA1)
from the beginning, perhaps we do not have to rename _ORIGINAL later?