Re: [RFC][PATCH 0/32] SHA256 and SHA1 interoperability

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 10, 2023, 15:38 UTC
Message-ID: <ZP3i9WdpDKlsWuNP@tapette.crustytoothpaste.net>
In-Reply-To: <87sf7ol0z3.fsf@email.froward.int.ebiederm.org>

On 2023-09-08 at 23:05:52, Eric W. Biederman wrote:

Show 6 quoted lines

> 
> I would like to see the SHA256 transition happen so I started playing
> with the k2204-transition-interop branch of brian m. carlson's tree.
> 
> Before I go farther I need to some other folks to look at this and see
> if this is a general direction that the git project can stand.

I'm really excited to see this and I think it's a great way forward. I've taken a brief look at each patch, and I don't see anything that should be a dealbreaker. I left a few comments, although I think your mailserver is blocking mine at the moment, so you may not have received them (hopefully you can read them on the list in the interim).

You may also feel free to simply adjust the commit message for the patches of mine you've modified without needing to document that you've changed them. I expect that you will have changed them when you submit them, if only to resolve conflicts. After all, Junio does so all the time.

> This patchset is not complete it does not implement converting a
> received pack of the compatibility hash into the hash function of the
> repository, nor have I written any automated tests.  Both need to happen
> before this is finalized.

Speaking of tests, one set of tests I had intended to write and think should be written, but had not yet implemented, is tests for round-tripping objects. That is, the SHA-1 value we get for a revision in a pure SHA-1 repository should obviously be the same as the SHA-1 value we get in a SHA-256 repository in interop mode, and we should be able to use the `test_oid_cache` functionality to hard-code the desired objects. I think it would be also helpful to do this for fixed objects that are doubly-signed (with both algorithms) as well, since that's a tricky edge case that we'll want to avoid breaking. Other edge cases will include things like merge commits, including octopus merges.

But overall, I think this is a great improvement, and I'm very excited to see someone picking up some of this work and moving it forward. Thanks for doing so.

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