{"thread":{"id":"54639","subject":"[PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","startedAt":"2020-11-13T21:53:21Z","lastAt":"2020-11-19T15:45:06Z","messageCount":9,"participants":["SZEDER Gábor","Taylor Blau","brian m. carlson","Johannes Schindelin","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"409927","messageId":"20201113215307.20855-1-szeder.dev@gmail.com","threadId":"54639","inReplyTo":null,"subject":"[PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-11-13T21:53:07Z","receivedAt":"2020-11-13T21:53:21Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps\nare compatible with JGit's bitmaps. Alas, not even the most recent\nJGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this\ntest script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with\nJGit installed in PATH, then these two tests fail.\n\nProtect these two tests with the SHA1 prereq in order to skip them\nwhen testing with SHA256.\n\nSigned-off-by: SZEDER Gábor \n---\n t/t5310-pack-bitmaps.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh\nindex 8318781d2b..1d40fcad39 100755\n--- a/t/t5310-pack-bitmaps.sh\n+++ b/t/t5310-pack-bitmaps.sh\n@@ -277,7 +277,7 @@ test_expect_success 'pack with missing parent' '\n \tgit pack-objects --stdout --revs /dev/null\n '\n \n-test_expect_success JGIT 'we can read jgit bitmaps' '\n+test_expect_success JGIT,SHA1 'we can read jgit bitmaps' '\n \tgit clone --bare . compat-jgit.git &&\n \t(\n \t\tcd compat-jgit.git &&\n@@ -287,7 +287,7 @@ test_expect_success JGIT 'we can read jgit bitmaps' '\n \t)\n '\n \n-test_expect_success JGIT 'jgit can read our bitmaps' '\n+test_expect_success JGIT,SHA1 'jgit can read our bitmaps' '\n \tgit clone --bare . compat-us.git &&\n \t(\n \t\tcd compat-us.git &&\n-- \n2.29.2.612.g41c40d3f73\n\n"},{"id":"409928","messageId":"X68BJSbDjdRGpPOR@nand.local","threadId":"54639","inReplyTo":"20201113215307.20855-1-szeder.dev@gmail.com","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-11-13T21:56:53Z","receivedAt":"2020-11-13T21:56:58Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Fri, Nov 13, 2020 at 10:53:07PM +0100, SZEDER Gábor wrote:\n> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps\n> are compatible with JGit's bitmaps. Alas, not even the most recent\n> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this\n> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with\n> JGit installed in PATH, then these two tests fail.\n>\n> Protect these two tests with the SHA1 prereq in order to skip them\n> when testing with SHA256.\n\nThanks, this looks obviously good to me.\n\n Reviewed-by: Taylor Blau \n\nThanks,\nTaylor\n"},{"id":"409934","messageId":"20201113234319.GM6252@camp.crustytoothpaste.net","threadId":"54639","inReplyTo":"20201113215307.20855-1-szeder.dev@gmail.com","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-11-13T23:43:19Z","receivedAt":"2020-11-13T23:43:26Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-11-13 at 21:53:07, SZEDER Gábor wrote:\n> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps\n> are compatible with JGit's bitmaps. Alas, not even the most recent\n> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this\n> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with\n> JGit installed in PATH, then these two tests fail.\n> \n> Protect these two tests with the SHA1 prereq in order to skip them\n> when testing with SHA256.\n\nYeah, this seems like a reasonable thing to do.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"409976","messageId":"20201115211354.GB8033@szeder.dev","threadId":"54639","inReplyTo":"20201113215307.20855-1-szeder.dev@gmail.com","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-11-15T21:13:54Z","receivedAt":"2020-11-15T21:14:00Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Nov 13, 2020 at 10:53:07PM +0100, SZEDER Gábor wrote:\n> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps\n> are compatible with JGit's bitmaps. Alas, not even the most recent\n> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this\n> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with\n> JGit installed in PATH, then these two tests fail.\n\nSo both of those tests invoke 'jgit gc' which fails with the same\nerror message in both cases:\n\n + jgit gc\n fatal: Invalid id: 93b89bd36289ec88dd9db249a48da3e7440e46b94d3a93d98540062bec0e5ac1\n\nThis is clearly related to SHA256 (though I think JGit shouldn't even\nget as far as looking at object IDs, but should have errored out upon\nseeing the unsupported extensions.objectformat=sha256 in the config,\nand it's alarming that it didn't).\n\nNow, we do have one more JGit test: \"indicate no refs in\nstandards-compliant empty remote\" in 't5512-ls-remote.sh', which fails\nwith SHA256 as well... but the failure comes from 'git ls-remote':\n\n + test_expect_code 2 git ls-remote --exit-code git://localhost:5512/empty.git\n fatal: protocol error: unexpected capabilities^{}\n test_expect_code: command exited with 128, we wanted 2 git ls-remote --exit-code git://localhost:5512/empty.git\n\nThis doesn't at all look like an error related to SHA256, but I'm not\nup to speed with SHA256-specific protocol stuff... so I'm hesitant to\nsimply protect this test with the SHA1 prereq as well.\n\n"},{"id":"409995","messageId":"nycvar.QRO.7.76.6.2011152252520.18437@tvgsbejvaqbjf.bet","threadId":"54639","inReplyTo":"20201113215307.20855-1-szeder.dev@gmail.com","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-11-15T22:08:40Z","receivedAt":"2020-11-16T11:39:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Fri, 13 Nov 2020, SZEDER Gábor wrote:\n\n> In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps\n> are compatible with JGit's bitmaps. Alas, not even the most recent\n> JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this\n> test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with\n> JGit installed in PATH, then these two tests fail.\n\nI wonder whether there is a way to change the `JGIT` prereq in a way\nthat automagically will recognize a (future) SHA256-enabled JGit?\nSomething like\n\ntest_lazy_prereq JGIT '\n\tjgit --version &&\n test_have_prereq !SHA1 ||\n\ttest \"$(git rev-list -n 1 HEAD)\" = \"$(jgit rev-list -n 1 HEAD)\"\n'\n\nWhat do you think?\n\nCiao,\nDscho\n\n>\n> Protect these two tests with the SHA1 prereq in order to skip them\n> when testing with SHA256.\n>\n> Signed-off-by: SZEDER Gábor \n> ---\n> t/t5310-pack-bitmaps.sh | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh\n> index 8318781d2b..1d40fcad39 100755\n> --- a/t/t5310-pack-bitmaps.sh\n> +++ b/t/t5310-pack-bitmaps.sh\n> @@ -277,7 +277,7 @@ test_expect_success 'pack with missing parent' '\n> \tgit pack-objects --stdout --revs /dev/null\n> '\n>\n> -test_expect_success JGIT 'we can read jgit bitmaps' '\n> +test_expect_success JGIT,SHA1 'we can read jgit bitmaps' '\n> \tgit clone --bare . compat-jgit.git &&\n> \t(\n> \t\tcd compat-jgit.git &&\n> @@ -287,7 +287,7 @@ test_expect_success JGIT 'we can read jgit bitmaps' '\n> \t)\n> '\n>\n> -test_expect_success JGIT 'jgit can read our bitmaps' '\n> +test_expect_success JGIT,SHA1 'jgit can read our bitmaps' '\n> \tgit clone --bare . compat-us.git &&\n> \t(\n> \t\tcd compat-us.git &&\n> --\n> 2.29.2.612.g41c40d3f73\n>\n>\n"},{"id":"410256","messageId":"20201118183022.GA8396@szeder.dev","threadId":"54639","inReplyTo":"nycvar.QRO.7.76.6.2011152252520.18437@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-11-18T18:30:22Z","receivedAt":"2020-11-18T18:30:35Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sun, Nov 15, 2020 at 11:08:40PM +0100, Johannes Schindelin wrote:\n> Hi Gábor,\n> \n> On Fri, 13 Nov 2020, SZEDER Gábor wrote:\n> \n> > In 't5310-pack-bitmaps.sh' two tests make sure that our pack bitmaps\n> > are compatible with JGit's bitmaps. Alas, not even the most recent\n> > JGit version (5.9.0.202009080501-r) supports SHA256 yet, so when this\n> > test script is run with GIT_TEST_DEFAULT_HASH=sha256 on a setup with\n> > JGit installed in PATH, then these two tests fail.\n> \n> I wonder whether there is a way to change the `JGIT` prereq in a way\n> that automagically will recognize a (future) SHA256-enabled JGit?\n> Something like\n> \n> test_lazy_prereq JGIT '\n> \tjgit --version &&\n> test_have_prereq !SHA1 ||\n> \ttest \"$(git rev-list -n 1 HEAD)\" = \"$(jgit rev-list -n 1 HEAD)\"\n> '\n> \n> What do you think?\n\nI'm not sure. It is surely a substantial effort to fully support\nSHA256, and I suppose there will be JGit versions with only partial\nsupport. I'm worried that there will be versions that can already\nread SHA256 objects, but can't read/write SHA256 pack bitmaps, or\ncan't transfer/negotiate SHA256 objects yet (for t5512), so even\nthough they could fulfill such a prereq test above, the test would\nstill fail.\n\n\n"},{"id":"410259","messageId":"20201118184543.GA3016@coredump.intra.peff.net","threadId":"54639","inReplyTo":"20201118183022.GA8396@szeder.dev","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-18T18:45:43Z","receivedAt":"2020-11-18T18:46:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 18, 2020 at 07:30:22PM +0100, SZEDER Gábor wrote:\n\n> > I wonder whether there is a way to change the `JGIT` prereq in a way\n> > that automagically will recognize a (future) SHA256-enabled JGit?\n> > Something like\n> > \n> > test_lazy_prereq JGIT '\n> > \tjgit --version &&\n> > test_have_prereq !SHA1 ||\n> > \ttest \"$(git rev-list -n 1 HEAD)\" = \"$(jgit rev-list -n 1 HEAD)\"\n> > '\n> > \n> > What do you think?\n> \n> I'm not sure. It is surely a substantial effort to fully support\n> SHA256, and I suppose there will be JGit versions with only partial\n> support. I'm worried that there will be versions that can already\n> read SHA256 objects, but can't read/write SHA256 pack bitmaps, or\n> can't transfer/negotiate SHA256 objects yet (for t5512), so even\n> though they could fulfill such a prereq test above, the test would\n> still fail.\n\nYeah, it's likely we'll need to just match the output of \"jgit\n--version\". Since their support is hypothetical at this point, I think\nit makes sense to go with your original patch. It does mean we'll later\nhave to remove the SHA1 prereq from those tests, but that's OK. It's not\nvery many tests, and your commit message clearly explains what is going\non.\n\n-Peff\n"},{"id":"410345","messageId":"nycvar.QRO.7.76.6.2011191215140.56@tvgsbejvaqbjf.bet","threadId":"54639","inReplyTo":"20201118184543.GA3016@coredump.intra.peff.net","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-11-19T11:19:10Z","receivedAt":"2020-11-19T11:19:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Wed, 18 Nov 2020, Jeff King wrote:\n\n> On Wed, Nov 18, 2020 at 07:30:22PM +0100, SZEDER Gábor wrote:\n>\n> > > I wonder whether there is a way to change the `JGIT` prereq in a way\n> > > that automagically will recognize a (future) SHA256-enabled JGit?\n> > > Something like\n> > >\n> > > test_lazy_prereq JGIT '\n> > > \tjgit --version &&\n> > > test_have_prereq !SHA1 ||\n> > > \ttest \"$(git rev-list -n 1 HEAD)\" = \"$(jgit rev-list -n 1 HEAD)\"\n> > > '\n> > >\n> > > What do you think?\n> >\n> > I'm not sure. It is surely a substantial effort to fully support\n> > SHA256, and I suppose there will be JGit versions with only partial\n> > support. I'm worried that there will be versions that can already\n> > read SHA256 objects, but can't read/write SHA256 pack bitmaps, or\n> > can't transfer/negotiate SHA256 objects yet (for t5512), so even\n> > though they could fulfill such a prereq test above, the test would\n> > still fail.\n>\n> Yeah, it's likely we'll need to just match the output of \"jgit\n> --version\". Since their support is hypothetical at this point, I think\n> it makes sense to go with your original patch. It does mean we'll later\n> have to remove the SHA1 prereq from those tests, but that's OK. It's not\n> very many tests, and your commit message clearly explains what is going\n> on.\n\nIt's not just removing the SHA-1 prereq, but testing for a new-enough\nversion.\n\nThis most likely entails adding a new test helper to `t/helper/` that\nallows using `versioncmp()` via the command-line, with some clever way to\nindicate the different outcomes, and then using that in a new prereq.\n\nYou know, if it was me, I would opt for the simpler (and future-proof)\nsolution I presented above. But hey, if that complex solution using\n`versioncmp()` floats your boat, who am I to stop you.\n\nCiao,\nDscho\n"},{"id":"410357","messageId":"20201119154458.GA25426@coredump.intra.peff.net","threadId":"54639","inReplyTo":"nycvar.QRO.7.76.6.2011191215140.56@tvgsbejvaqbjf.bet","subject":"Re: [PATCH] t5310-pack-bitmaps: skip JGit tests with SHA256","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-19T15:44:58Z","receivedAt":"2020-11-19T15:45:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 19, 2020 at 12:19:10PM +0100, Johannes Schindelin wrote:\n\n> > Yeah, it's likely we'll need to just match the output of \"jgit\n> > --version\". Since their support is hypothetical at this point, I think\n> > it makes sense to go with your original patch. It does mean we'll later\n> > have to remove the SHA1 prereq from those tests, but that's OK. It's not\n> > very many tests, and your commit message clearly explains what is going\n> > on.\n> \n> It's not just removing the SHA-1 prereq, but testing for a new-enough\n> version.\n> \n> This most likely entails adding a new test helper to `t/helper/` that\n> allows using `versioncmp()` via the command-line, with some clever way to\n> indicate the different outcomes, and then using that in a new prereq.\n> \n> You know, if it was me, I would opt for the simpler (and future-proof)\n> solution I presented above. But hey, if that complex solution using\n> `versioncmp()` floats your boat, who am I to stop you.\n\nBut that was my (and Gábor's) point: it is not future proof, because we\ndon't know whether it is a sufficient test until we actually see a\nversion of JGit with the correct support.\n\nNot only that, but your proposed solution relies on having commits in\nthe repository, which is not something that a prereq should be relying\non.\n\nWe may or may not need the version check eventually, but my point is\nthat we should be punting on it until we know what is needed.\n\n-Peff\n"}]}