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
