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

[Junio C Hamano <gitster@pobox.com>]

"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)?

> When Git
> 3.0 comes out, we can switch our GIT_TEST_DEFAULT_HASH test from sha256
> to sha1 to continue to verify that those work.  As I learned when
> writing the SHA-256 functionality and as I'm experiencing today writing
> the interop code, if clones, fetches, and pushes do not work properly,
> the testsuite is completely broken with at the very least fifty-some-odd
> tests failing, so I feel confident that functionality will continue to
> work for SHA-1 as long as we do run an appropriate test job.

OK.

> Also, when we initialize a SHA-1 repository with the files ref backend,
> we still use repository format version 0 without any extensions, so the
> cases that cover older-style configs will still be adequately tested. We
> also have some tests that even test that things work properly without a
> config file, which caught a bug in this series (that I fixed before
> sending it out).

Very nice.

Thanks.