Re: reftable & jgit compatibility

[Patrick Steinhardt <ps@pks.im>]

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

On Wed, Apr 03, 2024 at 04:54:51PM -0400, Jeff King wrote:
> On Wed, Apr 03, 2024 at 12:47:15PM +0200, Patrick Steinhardt wrote:
> 
> > 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/.

Oh, that's great, I didn't know about that! I will take a look at
updating our CI systems to include JGit...

> 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.

... also to avoid rotting tests like this.

> 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.

Agreed. I will add some basic interop tests that ensure that JGit and
CGit can read their respective formats. I don't want it to be too fancy
initially, but it's good to have a baseline which we can iterate from in
the future.

Patrick

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