On Fri, Mar 15, 2024 at 10:49:39AM +0900, Yasuhiro Kimura wrote:
> I expect the change is committed to 'main' branch. But actually it is
> committed to 'master' branch.
>
> Anything else you want to add:
>
> If I change step 2 as following,
>
> 2'. git clone /somewhere/test.git
>
> then I get expected behavior.
I suspect you are running afoul of two things:
1. When cloning a totally empty repository, detecting the destination
of the unborn HEAD requires a protocol extension. This extension
was implemented only for Git's v2 protocol, not for v0.
2. Git should automatically use v2 in most cases these days. But it
does so by probing the server in a backwards-compatible way to see
if it also supports v2. For ssh, that probe happens by passing a
special environment variable. However, the default config for many
ssh servers refuses unknown variables. For OpenSSH, you'd want to
add:
AcceptEnv GIT_PROTOCOL
to your sshd_config.
You can verify the protocol in use by running your clone with
GIT_TRACE_PACKET=1 in the environment. For v0, you'll see either a pair
of empty flush packets (for older versions of the server):
packet: clone< 0000
packet: clone> 0000
or a single-line capabilities faux-ref like:
packet: clone< 00000... capabilities^{}\0multi_ack thin-pack side-band etc...
For v2, the server will respond with a multi-line capabilities list,
starting with the version:
packet: clone< version 2
Assuming my guess is right, I think everything here is working as
designed, though obviously it's not a great outcome (and changing the
server-side config may not be an option for everyone).
Some possible things we could do to make it better:
a. teach v0 the same "unborn" extension that v2 knows (or maybe even
the existing symref extension would work on the capabilities line?)
This probably wouldn't be too hard, but I think there are many
other capabilities that v0 would still lack, so it's kind of a
losing battle.
b. as v0-only servers become more and more rare, it would be nice if
the client could start assuming v2 by default, rather than probing.
But I don't think this quite works, because it is the server who
starts speaking v2 first (and it won't do so without seeing that
probe). You could imagine the client invoking "git-upload-pack
--version=2" on the server, but of course no server implements that
option yet (and if you added it, you'd have to wait for the server
side support to percolate).
c. provide more ways to get the v2 probe information to the server.
For ssh, one obvious thing is to invoke "GIT_PROTOCOL=version=2
git-upload-pack" on the server, using the shell to set the
environment variable rather than passing it over ssh. We didn't do
that when we added v2 because there are backwards compatibility
failure modes (e.g., servers where the shell is not regular 'sh' or
where there might not be a shell at all, or restricted environments
which allow "git-upload-pack" to run but nothing else).
But maybe taking (b) and (c) together, we could add an option to ask the
client to pass the protocol variable via the shell. It doesn't have to
work everywhere because you'd enable it manually for servers where you
know it would work (and people configuring restricted servers probably
already made the necessary ssh config changes).
Of course the biggest challenging is users realizing that they need to
do something to enable v2 in the first place. For the most part v0 just
works, and so it is easy to not realize you're still using it.
-Peff
