git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git: prepare to regularly change hashsums

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Aug 21, 2025, 08:28 UTC
Message-ID
<aKbYvbWWL0FGXpG7@fruit.crustytoothpaste.net>
In-Reply-To
<e069a7ca-fba4-432a-9a05-a68b2b6ddbc7@hogyros.de>
On 2025-08-20 at 05:55:43, Simon Richter wrote:
Show 11 quoted lines
> 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
Previous: Simon Richter
Message 4 of 4 in “git: prepare to regularly change hashsums”
  1. Askar SafinAug 19, 2025
  2. brian m. carlsonAug 19, 2025
  3. Simon RichterAug 20, 2025
  4. brian m. carlsonAug 21, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.