Repository cloned using SSH does not respect bare repository initial branch

Hi Maintainers,

Repository cloned using SSH does not use the branch configured in the bare repository however repository cloned using filesystem does as expected. Shouldn't they both behave the same?

Thanks Sheik

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

#Create bare repository
     su - $user
     git init --bare --initial-branch=test test.git

#Clone repository
     git clone ssh://$user@$computer:/home/$user/test.git test1
     cd test1

     git remote show origin
     #Output [ORIGIN1]

     echo abc >> abc.txt && git add * && git commit -a -m test && git push
     #Output...
     #* [new branch]      master -> master

     git remote show origin
     #Output [ORIGIN2]

What did you expect to happen? (Expected behavior) Repository cloned using ssh should push to test branch just like repository cloned using filesystem does below as configured in the bare repository.

#Clone repository
     git clone home/$user/test.git test2

     git remote show origin
     #Output [ORIGIN3]

     echo abc >> abc.txt && git add * && git commit -a -m test && git push

     #Output...
     #* [new branch]      test -> test

     git remote show origin
     #Output [ORIGIN4]

What happened instead? (Actual behavior) Repository cloned using ssh pushed to master branch disregarding configuration in bare repository.

What's different between what you expected and what actually happened? For ssh cloned repository test branch should been the default branch however master was the default.

Anything else you want to add:

[ORIGIN1]
* remote origin
   HEAD branch: (unknown)
   Local branch configured for 'git pull':
     master merges with remote master

[ORIGIN2]
* remote origin
   HEAD branch: (unknown)
   Remote branch:
     master tracked
   Local branch configured for 'git pull':
     master merges with remote master
   Local ref configured for 'git push':
     master pushes to master (up to date)

[ORIGIN3]
* remote origin
   HEAD branch: (unknown)
   Local branch configured for 'git pull':
     test merges with remote test

[ORIGIN4]
* remote origin
   HEAD branch: test
   Remote branches:
     master new (next fetch will store in remotes/origin)
     test   tracked
   Local branch configured for 'git pull':
     test merges with remote test
   Local ref configured for 'git push':
     test pushes to test (up to date)

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.42.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.5.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.6-1 (2023-10-07) x86_64 compiler info: gnuc: 13.2 libc info: glibc: 2.37 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks]

On Thu, Oct 26, 2023 at 07:36:36AM +1100, Sheik wrote:

What version of Git is running on the ssh server?

Your example seems to show that the parent repository has an unborn branch (i.e., HEAD points to "refs/heads/test", but there are no commits yet). I think the server-side bits you need for that to work showed up in 59e1205d16 (ls-refs: report unborn targets of symrefs, 2021-02-05), which is in v2.31.

So even though your client seems to be v2.42 (from the output you gave), if the server is older it may not be sending sufficient information. There were also some other fixes on top of that, but I _think_ they were all client-side (so your v2.42 clone command should be doing the right thing).

-Peff

Server version is same as client (v2.42.0) as I ran these commands all on the same machine.

Test on ssh server:

$ git -v --build-options

#Output

git version 2.42.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh

Thanks

Sheik

On 30/10/23 20:36, Jeff King wrote:

On Tue, Oct 31, 2023 at 02:24:46AM +1100, Sheik wrote:

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

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

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

Wondering whether a link to the protocol documentation should be added in "git init --initial-branch" to make this more obvious.

 1. https://git-scm.com/docs/git-init#Documentation/git-init.txt---initial-branchltbranch-namegt
 2. https://git-scm.com/docs/gitprotocol-v2

Thanks

Sheik

On 30/10/23 20:36, Jeff King wrote:

Confirming your observation above, yes this is a purely new bare repository which has no commits yet before cloning.

Thanks

Sheik