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:
signature.asc
Description: PGP signature
