Re: [PATCH 02/10] hash: add a constant for the original hash algorithm

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jun 20, 2025, 20:43 UTC
Message-ID: <aFXH2_PpZrJxJRCs@fruit.crustytoothpaste.net>
In-Reply-To: <xmqq1prf89cd.fsf@gitster.g>

On 2025-06-20 at 01:56:02, Junio C Hamano wrote:

Show 12 quoted lines

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > We have a a variety of uses of GIT_HASH_SHA1 littered throughout our
> > code.  Some of these really mean to represent specifically SHA-1, but
> > some actually represent the original hash algorithm used in Git which is
> > implied by older formats and protocols which do not contain hash
> > information.  For instance, the bundle v1 and v2 formats do not contain
> > hash algorithm information, and thus SHA-1 is implied by the use of
> > these formats.
> 
> Does that mean use of _ORIGINAL is a sign that these places should
> keep using SHA-1 and should not change?

Yes.

Show 7 quoted lines

> I am having a hard time guessing/assessing the value of having _ORIGINAL
> that is a synonym for _SHA1; with redirection, it pretends as if the
> underlying value can be updated from SHA-1 to SHA-256 (and that is
> the very intention behind GIT_HASH_DEFAULT symbol that gives us a
> level of indirection), but it is hard to imagine we would ever want
> to change what _ORIGINAL means, as that word talks about a historical
> fact that will never change over time.

I agree. _ORIGINAL indicates that this is a use of SHA-1 which is a historical fact and is a legacy decision as opposed to one specified explicitly.

For instance, if we're setting the algorithm for bundle v1 and v2, then we'd use _ORIGINAL because those formats did not specify a hash value when they were designed and, for legacy reasons, we cannot change that fact. However, if with bundle v3, a user specified @object-format=sha1, then we'd use _SHA1, since that was an explicit decision documented. Similarly, _SHA1 represents extensions.objectFormat=sha1, which is an intentional decision to use the older algorithm.

Show 9 quoted lines

> > Add a constant for documentary purposes which indicates this value.  It
> > will always be the same as SHA-1, since this is an essential part of
> > these formats, but its use indicates this particular reason and not any
> > other reason why SHA-1 might be used.
> 
> I am not sure what this means.  If we use GIT_HASH_SHA1 in such
> places explicitly (as opposed to GIT_HASH_DEFAULT), isn't it a sign
> enough that with different versions of Git, that particular code
> path should keep using SHA-1 no matter what the default is?

If we have a test helper that computes hashes and someone specified "sha1" on the command line, that's GIT_HASH_SHA1. Someone said, "I'd like to use SHA-1." Similarly, in the reftable code, we can read the byte value indicating that the reftable is in SHA-1 and that's an explicit decision.

If we default to SHA-1 because nobody specified extensions.objectformat, then that's GIT_HASH_ORIGINAL. Nobody made a decision or opted into an algorithm; we just didn't think hard enough about cryptographic agility in the original Git and we assumed SHA-1.

They're both the same numeric constant here and always will be (even if, in a future version of Git, we get rid of SHA-1 altogether and we otherwise die on that code). But there's a difference in intention: one explicitly stated SHA-1 as opposed to a different algorithm and one just got a default because that's the compatible legacy behaviour.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA