Just so there is no misunderstanding it seems that a year ago people were having trouble with git on Savannah but instead of opening a discussion about it with any Savannah or FSF admins they talked about it elsewhere on a non-free platform where no one with any connection to Savannah would see it. That's a correct assessment, right?

Sorry I didn't respond sooner.  I read your report.  But I couldn't
think of any reason why things might be very slow for you.  This is my
first chance to post that I am sorry but I don't have a clue.  It
works for me and I can clone and push to repositories and things are
fast for me.

rwp@angst:/tmp/junk$ time git clone git.savannah.gnu.org:/srv/git/emacs/org-mode.git
Cloning into 'org-mode'...
remote: Counting objects: 135896, done.
remote: Compressing objects: 100% (29366/29366), done.
remote: Total 135896 (delta 106451), reused 135807 (delta 106390)
Receiving objects: 100% (135896/135896), 88.42 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (106451/106451), done.

real    1m2.819s
user    0m58.152s
sys     0m2.361s
rwp@angst:/tmp/junk$ cd org-mode
bob@hysteria:/tmp/junk/org-mode$ time git pull
Already up to date.

real    0m4.458s
user    0m0.203s
sys     0m0.022s

I am in Colorado so this has to work across the country.  I do have a
fast home connection on a fiber network.  (Finally!)  But it is a good
test across the country and across the Internet router connections.

> debug1: /home/tec/.ssh/config line 81: Applying options for *
> debug1: /usr/etc/ssh/ssh_config line 27: Applying options for *

What options are being applied there?  They might be incompatible.

> debug1: auto-mux: Trying existing master
> debug1: multiplexing control connection
> debug2: fd 13 setting O_NONBLOCK
> debug3: fd 13 is O_NONBLOCK
> debug1: channel 5: new [mux-control]
> debug3: channel_post_mux_listener: new mux channel 5 fd 13
> debug3: mux_master_read_cb: channel 5: hello sent
> debug3: mux_master_read_cb: channel 5 packet type 0x00000001 len 4
> debug2: mux_master_process_hello: channel 5 client version 4
> debug3: mux_master_read_cb: channel 5 packet type 0x10000004 len 4
> debug2: mux_master_process_alive_check: channel 5: alive check
> debug3: mux_master_read_cb: channel 5 packet type 0x10000002 len 70
> debug2: mux_master_process_new_session: channel 5: request tty 1, X 0, agent 0, subsys 0, term "xterm-256color", cmd "", env 1
> debug3: mux_master_process_new_session: got fds stdin 14, stdout 15, stderr 16
> debug1: channel 6: new [client-session]
> debug2: mux_master_process_new_session: channel_new: 6 linked to control channel 5
> debug2: channel 6: send open
> debug3: send packet: type 90

This looks like your configuration is trying to use a ControlMaster to
reuse a previous connection.  That can't work.  And, I don't know, but
it feels suspicious that this might be part of the problem.  I suggest
removing any ControlMaster configuration for Savannah as that requires
both a persistent connection and auxiliary ports both of which are
restricted.

I believe you can configure ssh to avoid specific sites.  For example
I am pretty sure (needs to be tested) that one can specify a host
section this way and avoid having it take effect for the negated
pattern.

Host !.gnu.org

And that is all I can think of at the moment.  No one else is
reporting unusuably slow data transfer.  Therefore it seems the
problem is most likely on your end of the connection.  In which case
only you on your end can debug it.

I am happy to help in the debugging in any way possible.  Let me know
how I can help.