| Message ID | 20201113215307.20855-1-szeder.dev@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 72fb4e7155f6939953d7aa5ddfbc2c0321a626f3 |
| Headers | show |
| Series | t5310-pack-bitmaps: skip JGit tests with SHA256 | expand |
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
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.
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.
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 > >
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.
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
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
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
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 &&
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(-)