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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]

On 2025-06-20 at 20:42:52, Junio C Hamano wrote:
> "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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]