Re: Name for initial branch is ignored when repository is cloned with SSH

On Fri, Mar 15, 2024 at 10:49:39AM +0900, Yasuhiro Kimura wrote:

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