Re: git: prepare to regularly change hashsums

From: Simon Richter <simon.richter@hogyros.de>
Date: Aug 20, 2025, 05:55 UTC
Message-ID: <e069a7ca-fba4-432a-9a05-a68b2b6ddbc7@hogyros.de>
In-Reply-To: <aKTqHTnOMp1LFNLD@fruit.crustytoothpaste.net>

Hi,

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

Show 6 quoted lines

> 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