From: Sheik <sahibzone@gmail.com>
Date: Mon, 30 Oct 2023 23:30:29 GMT
Subject: Re: Repository cloned using SSH does not respect bare repository initial branch
Message-ID: <9cec7307-a875-4b8c-9abe-81c8879d698b@gmail.com>
In-Reply-To: <20231030174307.GA854621@coredump.intra.peff.net>

On 31/10/23 04:43, Jeff King wrote:

> On Tue, Oct 31, 2023 at 02:24:46AM +1100, Sheik wrote:
>
>> Server version is same as client (v2.42.0) as I ran these commands all on
>> the same machine.
> OK. The next thing I'd check is running both commands with:
>
>    GIT_TRACE_PACKET=1 git clone ...
>
> to see the protocol trace, and how it differs between the two. What I
> suspect you may see is that the local clone is using the "v2" protocol
> (a capabilities report, followed by "ls-refs", which mentions the symref
> value of HEAD), and the ssh one uses the older "v0" (it goes straight to
> the ref advertisement).
>
> Quoting from 59e1205d16 (ls-refs: report unborn targets of symrefs,
> 2021-02-05), the commit I mentioned before:
>
>      This change is only for protocol v2. A similar change for protocol
>      v0 would require independent protocol design (there being no
>      analogous position to signal support for "unborn") and client-side
>      plumbing of the data required, so the scope of this patch set is
>      limited to protocol v2.
>
> So in v0 the server doesn't pass back sufficient information for the
> client to know about the name of the unborn HEAD branch.
>
> If that's the culprit, the next question of course is why we'd do v2
> locally versus v0 overssh. And that probably has to do with how we
> trigger the protocol upgrade. To see if the server supports v2, the
> client passes extra information "out of band". For git-over-http, this
> happens in an extra HTTP header. For local repositories, it happens in
> an environment variable ($GIT_PROTOCOL). For git-over-ssh it happens in
> that sameenvironment variable, which we instruct the ssh client to pass
> using "-o SendEnv". But:
>
>    1. If your ssh client doesn't look like openssh, we don't know if it
>       supports "-o" and may skip it. See the discussion in ssh.variant in
>       "git help config".
>
>    2. Some servers need to be configured to allow the client to set
>       environment variables. In the case of openssh, you'd want a line
>       like this in your sshd_config file:
>
>         AcceptEnv GIT_PROTOCOL
>
> Of the two, I'd guess that the second one is more likely to be your
> problem (since you're running Linux, where openssh is the norm).
>
> -Peff


Thanks Jeff, tracing and setting the AcceptEnv indeed did the trick and 
workflow now works as expected.

Test steps on Debian/OpenSsh:

Server
1. Edit /etc/ssh/sshd_config
2. Add AcceptEnv GIT_PROTOCOL
3. systemctl restart sshd

Client
1. Enable ssh logging:
    export GIT_SSH_COMMAND=ssh -v
2. git clone ...
3. Output from ssh shows variable being sent (although regardless if 
AcceptEnv was set or not):
    debug1: channel 0: setting env GIT_PROTOCOL = "version=2"
    debug2: channel 0: request env confirm 0

References
1. 
https://git-scm.com/docs/git/2.42.0#Documentation/git.txt-codeGITPROTOCOLcode 

2. https://git-scm.com/docs/gitprotocol-v2#_ssh_and_file_transport
3. 
https://git-scm.com/docs/git/2.42.0#Documentation/git.txt-codeGITSSHCOMMANDcode 


Thanks
Sheik