git: prepare to regularly change hashsums

git: prepare to regularly change hashsums

[Askar Safin]

Hi, git people. I just noticed that you plan to change default hashsum in git 3.0.
Cool!

Please, prepare for regular change of hashsum.
No hash is forever. Be prepared to change hashsum algorithm once in 10 years.
See here for details, i. e. why no hash is forever: https://valerieaurora.org/hash.html

--
Askar Safin
https://types.pl/@safinaskar

Re: git: prepare to regularly change hashsums

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On 2025-08-19 at 14:25:27, Askar Safin wrote:
> Hi, git people. I just noticed that you plan to change default hashsum in git 3.0.
> Cool!

Thanks, I'm glad you're excited about it.  I am, too.

> Please, prepare for regular change of hashsum.
> No hash is forever. Be prepared to change hashsum algorithm once in 10 years.
> See here for details, i. e. why no hash is forever: https://valerieaurora.org/hash.html

Yes, this was a goal of the project when I did that work.

There are many fewer places where we have hard-coded hash values in the
tests and a lot more places where we compute values (for instance, if
what the test wants to know is that we're three commits before HEAD,
then we write `HEAD~3` instead of a specific object ID).  Instead of
lots of hard-coded 20- and 40-based constants throughout the code, we
have a few #define constants and a hash algorithm abstraction.

If we need to change the hash algorithm again, it will require
substantially less work, and we'll have only 40 test files to change
this time (which is a major improvement over last time).

I hope people also feel that the refactoring we did has made our
codebase easier to understand and more maintainable.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: git: prepare to regularly change hashsums

[Simon Richter]

Hi,

On 8/20/25 6:18 AM, brian m. carlson wrote:

> There are many fewer places where we have hard-coded hash values in the
> tests and a lot more places where we compute values (for instance, if
> what the test wants to know is that we're three commits before HEAD,
> then we write `HEAD~3` instead of a specific object ID).  Instead of
> lots of hard-coded 20- and 40-based constants throughout the code, we
> have a few #define constants and a hash algorithm abstraction.

For me it would be great to still be able to use commit IDs in this way 
in the future.

My use case is a script that is able to build old versions of a project, 
basically it is a long list of commit IDs that require me to change the 
build instructions, and "is-child-of" tests.

So e.g. in a project we switch from cmake to meson, and the CI script 
checks if the commit we are building is derived from the commit that 
switches cmake to meson (which has a known ID), if so, it configures 
using meson, if not, it checks more commit IDs to find out if it should 
use cmake, or just plain make.

So if the hash algorithm changes I need to either still be able to make 
ancestor tests using the old IDs, or a quick way to convert them.

    Simon

Re: git: prepare to regularly change hashsums

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

On 2025-08-20 at 05:55:43, Simon Richter wrote:
> On 8/20/25 6:18 AM, brian m. carlson wrote:
> 
> > There are many fewer places where we have hard-coded hash values in the
> > tests and a lot more places where we compute values (for instance, if
> > what the test wants to know is that we're three commits before HEAD,
> > then we write `HEAD~3` instead of a specific object ID).  Instead of
> > lots of hard-coded 20- and 40-based constants throughout the code, we
> > have a few #define constants and a hash algorithm abstraction.
> 
> For me it would be great to still be able to use commit IDs in this way in
> the future.

You can continue to do use object IDs for this purpose: we're not
removing them or deprecating them in any way.  It's merely that for our
testsuite we're relying less on object IDs to make it less brittle.

> So if the hash algorithm changes I need to either still be able to make
> ancestor tests using the old IDs, or a quick way to convert them.

Existing repositories will continue to use SHA-1 unless you actively
convert them.  The change is simply that _new_ repositories will use
SHA-256 by default (again, you can say that you want to use SHA-1 for a
new repository, just as you can say you want to use SHA-256 now).

I am working on code for interoperability between the two algorithms
which will allow you to convert a repository simply by cloning into a
repository using both hash algorithms.  That is, the remote might be
SHA-1, but your repository will have SHA-256 with SHA-1 compatibility
enabled, and then you'll have both algorithms.  You'll be able to look
up SHA-1 object IDs in that repository very similarly to SHA-256 object
IDs and convert the two.

That code already exists and works if your repositories are not using
shallow clone, partial clone, or submodules.  It just has yet to be sent
upstream.  I need to improve a few things in the current status quo
before I can send out the series.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]