[PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[SZEDER Gábor]

In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps
are compatible with JGit's bitmaps.  Alas, not even the most recent
JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this
test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with
JGit installed in PATH, then these two tests fail.

Protect these two tests with the SHA1 prereq in order to skip them
when testing with SHA256.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 t/t5310-pack-bitmaps.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 8318781d2b..1d40fcad39 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -277,7 +277,7 @@ test_expect_success 'pack with missing parent' '
 	git pack-objects --stdout --revs <revs >/dev/null
 '
 
-test_expect_success JGIT 'we can read jgit bitmaps' '
+test_expect_success JGIT,SHA1 'we can read jgit bitmaps' '
 	git clone --bare . compat-jgit.git &&
 	(
 		cd compat-jgit.git &&
@@ -287,7 +287,7 @@ test_expect_success JGIT 'we can read jgit bitmaps' '
 	)
 '
 
-test_expect_success JGIT 'jgit can read our bitmaps' '
+test_expect_success JGIT,SHA1 'jgit can read our bitmaps' '
 	git clone --bare . compat-us.git &&
 	(
 		cd compat-us.git &&
-- 
2.29.2.612.g41c40d3f73

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[Taylor Blau]

On Fri, Nov 13, 2020 at 10:53:07PM +0100, SZEDER Gábor wrote:
> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps
> are compatible with JGit's bitmaps.  Alas, not even the most recent
> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this
> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with
> JGit installed in PATH, then these two tests fail.
>
> Protect these two tests with the SHA1 prereq in order to skip them
> when testing with SHA256.

Thanks, this looks obviously good to me.

  Reviewed-by: Taylor Blau <me@ttaylorr.com>

Thanks,
Taylor

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[brian m. carlson]

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

On 2020-11-13 at 21:53:07, SZEDER Gábor wrote:
> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps
> are compatible with JGit's bitmaps.  Alas, not even the most recent
> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this
> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with
> JGit installed in PATH, then these two tests fail.
> 
> Protect these two tests with the SHA1 prereq in order to skip them
> when testing with SHA256.

Yeah, this seems like a reasonable thing to do.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[SZEDER Gábor]

On Fri, Nov 13, 2020 at 10:53:07PM +0100, SZEDER Gábor wrote:
> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps
> are compatible with JGit's bitmaps.  Alas, not even the most recent
> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this
> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with
> JGit installed in PATH, then these two tests fail.

So both of those tests invoke 'jgit gc' which fails with the same
error message in both cases:

  + jgit gc
  fatal: Invalid id: 93b89bd36289ec88dd9db249a48da3e7440e46b94d3a93d98540062bec0e5ac1

This is clearly related to SHA256 (though I think JGit shouldn't even
get as far as looking at object IDs, but should have errored out upon
seeing the unsupported extensions.objectformat=sha256 in the config,
and it's alarming that it didn't).

Now, we do have one more JGit test: "indicate no refs in
standards-compliant empty remote" in 't5512-ls-remote.sh', which fails
with SHA256 as well... but the failure comes from 'git ls-remote':

  + test_expect_code 2 git ls-remote --exit-code git://localhost:5512/empty.git
  fatal: protocol error: unexpected capabilities^{}
  test_expect_code: command exited with 128, we wanted 2 git ls-remote --exit-code git://localhost:5512/empty.git

This doesn't at all look like an error related to SHA256, but I'm not
up to speed with SHA256-specific protocol stuff...  so I'm hesitant to
simply protect this test with the SHA1 prereq as well.

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[Johannes Schindelin]

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

Hi Gábor,

On Fri, 13 Nov 2020, SZEDER Gábor wrote:

> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps
> are compatible with JGit's bitmaps.  Alas, not even the most recent
> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this
> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with
> JGit installed in PATH, then these two tests fail.

I wonder whether there is a way to change the `JGIT` prereq in a way
that automagically will recognize a (future) SHA256-enabled JGit?
Something like

test_lazy_prereq JGIT '
	jgit --version &&
        test_have_prereq !SHA1 ||
	test "$(git rev-list -n 1 HEAD)" = "$(jgit rev-list -n 1 HEAD)"
'

What do you think?

Ciao,
Dscho

>
> Protect these two tests with the SHA1 prereq in order to skip them
> when testing with SHA256.
>
> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> ---
>  t/t5310-pack-bitmaps.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
> index 8318781d2b..1d40fcad39 100755
> --- a/t/t5310-pack-bitmaps.sh
> +++ b/t/t5310-pack-bitmaps.sh
> @@ -277,7 +277,7 @@ test_expect_success 'pack with missing parent' '
>  	git pack-objects --stdout --revs <revs >/dev/null
>  '
>
> -test_expect_success JGIT 'we can read jgit bitmaps' '
> +test_expect_success JGIT,SHA1 'we can read jgit bitmaps' '
>  	git clone --bare . compat-jgit.git &&
>  	(
>  		cd compat-jgit.git &&
> @@ -287,7 +287,7 @@ test_expect_success JGIT 'we can read jgit bitmaps' '
>  	)
>  '
>
> -test_expect_success JGIT 'jgit can read our bitmaps' '
> +test_expect_success JGIT,SHA1 'jgit can read our bitmaps' '
>  	git clone --bare . compat-us.git &&
>  	(
>  		cd compat-us.git &&
> --
> 2.29.2.612.g41c40d3f73
>
>

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[SZEDER Gábor]

On Sun, Nov 15, 2020 at 11:08:40PM +0100, Johannes Schindelin wrote:
> Hi Gábor,
> 
> On Fri, 13 Nov 2020, SZEDER Gábor wrote:
> 
> > In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps
> > are compatible with JGit's bitmaps.  Alas, not even the most recent
> > JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this
> > test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with
> > JGit installed in PATH, then these two tests fail.
> 
> I wonder whether there is a way to change the `JGIT` prereq in a way
> that automagically will recognize a (future) SHA256-enabled JGit?
> Something like
> 
> test_lazy_prereq JGIT '
> 	jgit --version &&
>         test_have_prereq !SHA1 ||
> 	test "$(git rev-list -n 1 HEAD)" = "$(jgit rev-list -n 1 HEAD)"
> '
> 
> What do you think?

I'm not sure.  It is surely a substantial effort to fully support
SHA256, and I suppose there will be JGit versions with only partial
support.  I'm worried that there will be versions that can already
read SHA256 objects, but can't read/write SHA256 pack bitmaps, or
can't transfer/negotiate SHA256 objects yet (for t5512), so even
though they could fulfill such a prereq test above, the test would
still fail.

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[Jeff King]

On Wed, Nov 18, 2020 at 07:30:22PM +0100, SZEDER Gábor wrote:

> > I wonder whether there is a way to change the `JGIT` prereq in a way
> > that automagically will recognize a (future) SHA256-enabled JGit?
> > Something like
> > 
> > test_lazy_prereq JGIT '
> > 	jgit --version &&
> >         test_have_prereq !SHA1 ||
> > 	test "$(git rev-list -n 1 HEAD)" = "$(jgit rev-list -n 1 HEAD)"
> > '
> > 
> > What do you think?
> 
> I'm not sure.  It is surely a substantial effort to fully support
> SHA256, and I suppose there will be JGit versions with only partial
> support.  I'm worried that there will be versions that can already
> read SHA256 objects, but can't read/write SHA256 pack bitmaps, or
> can't transfer/negotiate SHA256 objects yet (for t5512), so even
> though they could fulfill such a prereq test above, the test would
> still fail.

Yeah, it's likely we'll need to just match the output of "jgit
--version". Since their support is hypothetical at this point, I think
it makes sense to go with your original patch. It does mean we'll later
have to remove the SHA1 prereq from those tests, but that's OK. It's not
very many tests, and your commit message clearly explains what is going
on.

-Peff

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[Johannes Schindelin]

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

Hi Peff,

On Wed, 18 Nov 2020, Jeff King wrote:

> On Wed, Nov 18, 2020 at 07:30:22PM +0100, SZEDER Gábor wrote:
>
> > > I wonder whether there is a way to change the `JGIT` prereq in a way
> > > that automagically will recognize a (future) SHA256-enabled JGit?
> > > Something like
> > >
> > > test_lazy_prereq JGIT '
> > > 	jgit --version &&
> > >         test_have_prereq !SHA1 ||
> > > 	test "$(git rev-list -n 1 HEAD)" = "$(jgit rev-list -n 1 HEAD)"
> > > '
> > >
> > > What do you think?
> >
> > I'm not sure.  It is surely a substantial effort to fully support
> > SHA256, and I suppose there will be JGit versions with only partial
> > support.  I'm worried that there will be versions that can already
> > read SHA256 objects, but can't read/write SHA256 pack bitmaps, or
> > can't transfer/negotiate SHA256 objects yet (for t5512), so even
> > though they could fulfill such a prereq test above, the test would
> > still fail.
>
> Yeah, it's likely we'll need to just match the output of "jgit
> --version". Since their support is hypothetical at this point, I think
> it makes sense to go with your original patch. It does mean we'll later
> have to remove the SHA1 prereq from those tests, but that's OK. It's not
> very many tests, and your commit message clearly explains what is going
> on.

It's not just removing the SHA-1 prereq, but testing for a new-enough
version.

This most likely entails adding a new test helper to `t/helper/` that
allows using `versioncmp()` via the command-line, with some clever way to
indicate the different outcomes, and then using that in a new prereq.

You know, if it was me, I would opt for the simpler (and future-proof)
solution I presented above. But hey, if that complex solution using
`versioncmp()` floats your boat, who am I to stop you.

Ciao,
Dscho

Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256

[Jeff King]

On Thu, Nov 19, 2020 at 12:19:10PM +0100, Johannes Schindelin wrote:

> > Yeah, it's likely we'll need to just match the output of "jgit
> > --version". Since their support is hypothetical at this point, I think
> > it makes sense to go with your original patch. It does mean we'll later
> > have to remove the SHA1 prereq from those tests, but that's OK. It's not
> > very many tests, and your commit message clearly explains what is going
> > on.
> 
> It's not just removing the SHA-1 prereq, but testing for a new-enough
> version.
> 
> This most likely entails adding a new test helper to `t/helper/` that
> allows using `versioncmp()` via the command-line, with some clever way to
> indicate the different outcomes, and then using that in a new prereq.
> 
> You know, if it was me, I would opt for the simpler (and future-proof)
> solution I presented above. But hey, if that complex solution using
> `versioncmp()` floats your boat, who am I to stop you.

But that was my (and Gábor's) point: it is not future proof, because we
don't know whether it is a sufficient test until we actually see a
version of JGit with the correct support.

Not only that, but your proposed solution relies on having commits in
the repository, which is not something that a prereq should be relying
on.

We may or may not need the version check eventually, but my point is
that we should be punting on it until we know what is needed.

-Peff