Re: [PATCH v3 8/8] ci: improve reftable test coverage

[Patrick Steinhardt <ps@pks.im>]

On Wed, Oct 14, 2026 at 07:13:44AM -0400, Jeff King wrote:
> On Wed, Oct 14, 2026 at 12:35:17PM +0200, Patrick Steinhardt wrote:
> 
> > > > Instead, adapt the job to run reftables together with SHA256. which is
> > > > an area that we don't have test coverage for.
> > > 
> > > Hmm. Aren't both sha256 and reftables by default part of the breaking
> > > changes flag? So I think we probably are already getting coverage there.
> > 
> > SHA256 is, but reftables is not. Quoting "t/test-lib.sh":
> > 
> >   GIT_TEST_BUILTIN_HASH=$("$GIT_BINARY" version --build-options | sed -ne 's/^default-hash: //p')
> >   GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-$GIT_TEST_BUILTIN_HASH}"
> >   export GIT_DEFAULT_HASH
> >   GIT_DEFAULT_REF_STORAGE_FORMAT="${GIT_TEST_DEFAULT_REF_STORAGE_FORMAT:-files}"
> >   export GIT_DEFAULT_REF_STORAGE_FORMAT
> > 
> > So we will run our tests with the default hash function, but we will
> > run with the "files" backend by default.
> 
> Ah, OK. That feels...weird, since the point of WITH_BREAKING_CHANGES is
> to check the new changes. Maybe reftables aren't breaking enough? :)

Yeah, I agree it's weird.

> I'd say we can punt it to another day, but if we _do_ think it's a bug,
> and we fix it, then that would make this new job pointless. I dunno.
> Maybe there is a good reason we are not pulling the ref format from
> build-options in the same way.

As you mentioned in a preceding message, it's probably just that stuff
has grown organically. We added the job when reftables was not slated as
a breaking change, so we couldn't really pull it from the build-options
at that point in time.

I'd punt on this for now and just leave this as-is, because right now it
increases our test coverage. But if we revisit I agree we should figure
out whether this job is still worth it.

Patrick