Re: [PATCH 10/10] Enable SHA-256 by default in breaking changes mode

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jun 20, 2025, 21:06 UTC
Message-ID: <aFXNaItMBiPm8t-_@fruit.crustytoothpaste.net>
In-Reply-To: <xmqqa5622lgz.fsf@gitster.g>

On 2025-06-20 at 20:42:52, Junio C Hamano wrote:

Show 21 quoted lines

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > On 2025-06-20 at 15:03:23, Junio C Hamano wrote:
> >> Another thing that I suspect nobody wrote tests for, but we must be
> >> absolutely certain, is that the post-3.0 Git can still interoperate
> >> well with historical SHA-1 repositories (I am not talking about
> >> "fetch from SHA-1 into SHA-256", but "the binary does not lose
> >> ability to work in SHA-1 repositories or fetch/push between SHA-1
> >> repositories, only because the default is set to SHA-256"), even in
> >> old repositories people have been using for ages without the
> >> core.repositoryformatversion defined.
> >
> > Yes, I have definitely tested that here before sending it out.
> 
> Is there a single t/tXXXX-*.sh test that is dedicated to that
> interoperability, or is it spread across commands (like,
> t????-clone-*.sh has a test that explicitly prepares an SHA-1 and an
> SHA-256 repositories and then tries to clone them with the current
> binary to make sure the result look reasonable, and t????-push-*.sh
> has a test to push between a pair of SHA-1 repositories, and a pair
> of SHA-256 repositories, with the current binary)?

For the dual-hash case, I will add interoperability tests in the future when we get the interoperability code working and I'll include same-hash, different-hash, and dual-hash cases. I'll also make sure that interop produces the same results in terms of object IDs that a native single-hash implementation provides. Right now on that code, I'm using GIT_DEFAULT_HASH=sha256:sha1 (which I added) to run the testsuite, which sets up SHA-256 as the main hash and SHA-1 as the compat hash. I'll add a CI job for that in the future. (If you're interested, this code is living in my sha256-interop branch on GitHub and my local server.)

As far as the tests we have right now that apply to this series, it's spread across a lot of tests. There are lots of places in the code that we clone a repository to make some changes that we don't want to make in the current repository, for instance, and if clones don't work then those tests are all broken. The submodule tests actually add a wide variety of nested repositories and push and pull them all over the place, so those also exercise all the cases very well. We do have clone and fetch tests, as well as push tests, for local, HTTP, and SSH, so we do get very comprehensive tests. Most of those don't specifically choose different hash algorithms, though (although a few do); they only work with whatever the testsuite is doing.

Also, while I think some basic interoperability tests are helpful, there's no substitute for running the entire testsuite in SHA-1 mode because there are subtle variations in the protocol (e.g., HTTP is stateless) and there are a lot of non-protocol cases we need to adequately cover as well (like initializing repositories). We're not going to catch all the weird edge cases with a few interoperability tests.

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