git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
@ 2020-11-13 21:53 SZEDER Gábor
  2020-11-13 21:56 ` Taylor Blau
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: SZEDER Gábor @ 2020-11-13 21:53 UTC (permalink / raw)
  To: git; +Cc: brian m. carlson, Junio C Hamano, 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-13 21:53 [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256 SZEDER Gábor
@ 2020-11-13 21:56 ` Taylor Blau
  2020-11-13 23:43 ` brian m. carlson
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 9+ messages in thread
From: Taylor Blau @ 2020-11-13 21:56 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: git, brian m. carlson, Junio C Hamano

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-13 21:53 [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256 SZEDER Gábor
  2020-11-13 21:56 ` Taylor Blau
@ 2020-11-13 23:43 ` brian m. carlson
  2020-11-15 21:13 ` SZEDER Gábor
  2020-11-15 22:08 ` Johannes Schindelin
  3 siblings, 0 replies; 9+ messages in thread
From: brian m. carlson @ 2020-11-13 23:43 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: git, Junio C Hamano

[-- 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 --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-13 21:53 [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256 SZEDER Gábor
  2020-11-13 21:56 ` Taylor Blau
  2020-11-13 23:43 ` brian m. carlson
@ 2020-11-15 21:13 ` SZEDER Gábor
  2020-11-15 22:08 ` Johannes Schindelin
  3 siblings, 0 replies; 9+ messages in thread
From: SZEDER Gábor @ 2020-11-15 21:13 UTC (permalink / raw)
  To: git; +Cc: brian m. carlson, Taylor Blau, Junio C Hamano

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-13 21:53 [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256 SZEDER Gábor
                   ` (2 preceding siblings ...)
  2020-11-15 21:13 ` SZEDER Gábor
@ 2020-11-15 22:08 ` Johannes Schindelin
  2020-11-18 18:30   ` SZEDER Gábor
  3 siblings, 1 reply; 9+ messages in thread
From: Johannes Schindelin @ 2020-11-15 22:08 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: git, brian m. carlson, Junio C Hamano

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-15 22:08 ` Johannes Schindelin
@ 2020-11-18 18:30   ` SZEDER Gábor
  2020-11-18 18:45     ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: SZEDER Gábor @ 2020-11-18 18:30 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, brian m. carlson, Junio C Hamano

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.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-18 18:30   ` SZEDER Gábor
@ 2020-11-18 18:45     ` Jeff King
  2020-11-19 11:19       ` Johannes Schindelin
  0 siblings, 1 reply; 9+ messages in thread
From: Jeff King @ 2020-11-18 18:45 UTC (permalink / raw)
  To: SZEDER Gábor
  Cc: Johannes Schindelin, git, brian m. carlson, Junio C Hamano

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-18 18:45     ` Jeff King
@ 2020-11-19 11:19       ` Johannes Schindelin
  2020-11-19 15:44         ` Jeff King
  0 siblings, 1 reply; 9+ messages in thread
From: Johannes Schindelin @ 2020-11-19 11:19 UTC (permalink / raw)
  To: Jeff King; +Cc: SZEDER Gábor, git, brian m. carlson, Junio C Hamano

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256
  2020-11-19 11:19       ` Johannes Schindelin
@ 2020-11-19 15:44         ` Jeff King
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2020-11-19 15:44 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: SZEDER Gábor, git, brian m. carlson, Junio C Hamano

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-11-19 15:52 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-13 21:53 [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256 SZEDER Gábor
2020-11-13 21:56 ` Taylor Blau
2020-11-13 23:43 ` brian m. carlson
2020-11-15 21:13 ` SZEDER Gábor
2020-11-15 22:08 ` Johannes Schindelin
2020-11-18 18:30   ` SZEDER Gábor
2020-11-18 18:45     ` Jeff King
2020-11-19 11:19       ` Johannes Schindelin
2020-11-19 15:44         ` Jeff King

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git