Re: [PATCH] remote-curl: fix clone on sha256 repos

On Tue, May 11, 2021 at 04:47:28PM +0200, Ævar Arnfjörð Bjarmason wrote:

On Tue, May 11 2021, Eric Wong wrote:

quoted

I'm not very familiar with the way some of this stuff works, but
the patch below seems to fix clone for me.

Me neither, but it seems that whatever issue we have here we've got a
big blind spot in our test suite.

GIT_SMART_HTTP in the environment will be ignored by test-lib.sh,
manually changing the code to use it leads to a lot of test failures,
some are definitely expected (incompatible server responses), but some
might not be...

There are specific dumb-http tests in t5550. And I think we can and do
run the suite with GIT_TEST_DEFAULT_HASH=sha256. But I suspect that
covers up the problem. If I understand the problem correctly, it comes
about when the client thinks the default hash is sha1, but the server is
sha256. Whereas GIT_TEST_DEFAULT_HASH affects _both_ sides.

So I think we'd want interop tests in t5550 that specifically create a
sha256 server and access it with a sha1 client (and possibly vice
versa).

It would be nice if there was a way to use an environment variable like
GIT_TEST_DEFAULT_HASH to mean "be hash X on the server, but Y on the
client". But I don't think we can easily do that. The "git init" command
which is used to create a repo that is later used for server access
doesn't _know_ that's what it's being used for. Possibly we could have
an extra variable that instructs git-clone to use a separate default
hash. And then:

  GIT_TEST_DEFAULT_HASH=sha256 \
  GIT_TEST_CLONE_DEFAULT_HASH=sha1 \
  make test

might possibly trigger some interesting cases.

-Peff