On Tue, Apr 25, 2023 at 04:12:15PM -0700, Junio C Hamano wrote:
> And I think even with "--no-local" to make it about v0/v1 protocol,
> the outcome is still pretty much expected. If we make the above
> command line to
>
> GIT_TRACE_PACKET=1 \
> git clone --no-local src256 dst256 &&
>
> to clone over the on-the-wire protocol, then we see
>
> Cloning into 'dst256'...
> packet: upload-pack> 0000
> packet: clone< 0000
> warning: You appear to have cloned an empty repository.
> packet: clone> 0000
> packet: upload-pack< 0000
> --- expect 2023-04-25 22:55:39.771850195 +0000
> ...
>
> in the output of "sh t5700-*.sh -i -v". Without any ref, v0/v1 can
> not carry any capabilities, because there is no ref information to
> tuck the capabilities on.
>
> I unfortunately doubt that any solution would exist that does not
> break compatibility with the deployed clients that expect the
> current v0/v1.
We could send a capabilities^{} line, which Git has supported on the
client side since eb398797cd (connect: advertized capability is not a
ref, 2016-09-09). So sending it should not break even old clients
(though we would have to check what alternate implementations like
libgit2 or dulwich do; we know JGit supports it).
However, the object-format support here was broken until the very recent
13e67aa39b (v0 protocol: fix sha1/sha256 confusion for capabilities^{},
2023-04-14), so it would only be useful going forward (before then we'd
die(), but maybe that is preferable to having the wrong object format?).
I'm not sure it's worth the effort, though. If you want to use sha256
everywhere and tell the other side about it, you need a modern client
anyway, and that means the ability to speak v2. So this would only
matter if for some reason the v2 probe was being ignored (e.g., proxies
eating it, ssh refusing environment variable, etc), which itself are
things that ideally would be fixed (and can maybe one day even go away
if we optimistically default to v2).
-Peff
