Question 37604 in Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Can a git repository use different transport protocols per branch? – Ubuntu

Server blocks outgoing SSH on port 22.

Trying to connect a new repo to an existing private GitHub repo.

On server:

git init .
git remote add [email protected]:<github_username>/repo_name.git

Strangest result sees my unable to communicate with GitHub whilst checked out into the main branch because it uses SSH transport.

However, on the only secondary branch, communication with GitHub works fine, seemingly because it’s connecting to a different domain: ssh.github.com and / or using HTTPS, however I do not recall ever connecting to the repository over HTTPS! Let alone for one branch and not the other.

git config --list only shows one URL:

push.default=simple
core.autocrlf=false
grep.linenumber=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.sshcommand=ssh -vvv
[email protected]:<github_username>/repo_name.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.main.remote=origin
branch.main.merge=refs/heads/main
branch.2nd.remote=origin
branch.2nd.merge=refs/heads/2nd

Debugging whilst checked out into ‘2nd’ branch:

debug2: resolving "ssh.github.com" port 443
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to ssh.github.com [20.248.137.50] port 443.
debug1: Connection established.

Debugging whilst checked out into ‘main’ branch:

debug2: resolving "github.com" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to github.com [20.248.137.48] port 22.
# Hangs here (firewall) but why the different address / protocol?

Has anyone experienced one branch attempting to use SSH transport whilst another uses HTTPS?

I wasn’t aware this was possible but it seemingly is.

Update for @LeGEC:

Within the ‘2nd’ branch:

ssh -vv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10+esm2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 1: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 22: Applying options for *
debug2: resolving "ssh.github.com" port 443
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to ssh.github.com [20.248.137.50] port 443.
debug1: Connection established.

So, again, ssh.github.com and 443

Within the ‘main’ branch:

ssh -vv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10+esm2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 22: Applying options for *
debug2: resolving "github.com" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to github.com [20.248.137.48] port 22.
debug1: Connection established.

And again, github.com and 22

Tags:

2

Answers


  1. 0

    Try and compare git config -l --show-origin --show-scope in both environments.
    That should show something related to ssh.github.com.

    Try also the same command after export GIT_TRACE2_EVENT=1: you can compare both event sets:

    export GIT_TRACE2_EVENT=~/log.event.main
git fetch origin main

export GIT_TRACE2_EVENT=~/log.event.2nd
git switch 2nd
git fetch origin 2nd

git diff --no-index --color-words=. ~/log.event.main ~/log.event.2nd
    Login or Signup to reply.
  2. 0

    There is a visible difference in your two ssh -vv outputs :

    in the first one ("Within the ‘2nd’ branch:"), you can see:

    debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 1: Applying options for github.com

    which doesn’t show up in the other trace.

    If your repo versions the ssh config files for the account you are running on, then this can obviously change the way ssh behaves if you change branches …

    Since that account appears to be root, I will also give you a very strong warning against using git in such a setup.

    git has good features for a versioning tool, it however has a few foot shooters and is definitely not a provisioning tool. You probably don’t want root to run hooks, to trigger merge conflicts in some central configuration files, or run git clean -f or git restore on your disk.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search