Re: reftable & jgit compatibility

From: Jeff King <peff@peff.net>
Date: Apr 3, 2024, 20:54 UTC
Message-ID: <20240403205451.GD1949464@coredump.intra.peff.net>
In-Reply-To: <Zg0zs2_QLpXv2PwT@tanuki>

On Wed, Apr 03, 2024 at 12:47:15PM +0200, Patrick Steinhardt wrote:

Show 6 quoted lines

> I very much agree, this thought has crossed my mind multiple times while
> working on the whole reftable saga. Ideally, we would have integration
> tests that write reftables with one of the implementations and then read
> them with the respective other implementation. I wouldn't really know
> where to put those though. CGit is very unlikely to pull in JGit as a
> test dependency. Does JGit have any tests that already use CGit?

We do have some tests that use jgit to check bitmap interoperability. But obviously they're optional, and I suspect they are not run very often (I do have jgit in my path these days, so I run them, but I assume most people don't). It probably wouldn't be too hard to include it in one of the CI runs, though. You can grep for the JGIT prereq in t/.

We had another test that used jgit to check for some protocol interoperability. But it was broken with sha256 and nobody noticed. ;) There I replaced it with a hard-coded input. See 13e67aa39b (v0 protocol: fix sha1/sha256 confusion for capabilities^{}, 2023-04-14) for some discussion.

I think using actual jgit (versus a hard-coded input) is a good basic smoke test: it tells us if the two can interoperate generally. But for testing specific inputs like the case in 13e67aa39b, we are depending on jgit producing that specific behavior (which in this case, it probably wasn't any more). And there we are better off just with a manual test vector.

-Peff