git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
May 11, 2021, 21:23 UTC
Message-ID
<YJr1y9jqguEQQXk3@coredump.intra.peff.net>
In-Reply-To
<YJrMNmH92mKrIX0N@coredump.intra.peff.net>
On Tue, May 11, 2021 at 02:25:58PM -0400, Jeff King wrote:
Show 13 quoted lines
> 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.
So this triggers several test failures:
diff --git a/builtin/clone.c b/builtin/clone.c
index eeb74c0217..622447daf7 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -992,6 +992,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 
 	packet_trace_identity("clone");
 
+	/* hack to test cross-hash interop */
+	{
+		const char *x = getenv("GIT_TEST_DEFAULT_CLONE_HASH");
+		if (x)
+			setenv("GIT_DEFAULT_HASH", x, 1);
+	}
+
 	git_config(git_clone_config, NULL);
 
 	argc = parse_options(argc, argv, prefix, builtin_clone_options,

For example, running:

  GIT_TEST_DEFAULT_CLONE_HASH=sha1 \
  GIT_TEST_DEFAULT_HASH=sha256 \
  ./t5550-http-fetch-dumb.sh -v -i

fails in test 3, which shows the problem Eric found. And indeed,
applying his patch fixes it. We then go on to fail in test 7 ("empty
dumb HTTP repository has default hash algorithm"), which is not all that
surprising, since there is no longer one "the default".

So I'm not sure if the technique is a good one. It did find a bug, but
it's not clear to me if the other dozen failures it finds are also bugs,
or places where the tests should be modified to handle this case, or
just weird problems caused by the hacky implementation above. A lot of
them seem to involve submodules, which is not surprising; we'd probably
end up here with a sha256 superproject and cloned sha1 modules.

-Peff
Previous: Junio C HamanoNext: brian m. carlson
Message 6 of 10 in “remote-curl: fix clone on sha256 repos”
  1. remote-curl: fix clone on sha256 reposEric Wong, May 11, 2021
  2. Junio C HamanoMay 11, 2021
  3. Ævar Arnfjörð BjarmasonMay 11, 2021
  4. Jeff KingMay 11, 2021
  5. Junio C HamanoMay 11, 2021
  6. Jeff KingMay 11, 2021
  7. brian m. carlsonMay 11, 2021
  8. brian m. carlsonMay 11, 2021
  9. Junio C HamanoMay 11, 2021
  10. brian m. carlsonMay 11, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.