Which is the smarter git protocol, ssh or git(over ssh) or https protocol?

Question

Which is efficient? SSH:// or Git:// (File compression)

I understand in Git, git protocol is smart because there is a protocol agent on both ends of communication to compress the file transfer resulting in faster clone by efficiently using the network bandwidth.

From an O'Reilly book I found the following statements.

For secure, authenticated connections, the Git native 
protocol can be tunneled over an SSH connection using
the following URL templates:

ssh: //[user@]example.com[:port]/path/to/repo.git
ssh: //[user@]example.com/path/to/repo.git
ssh: //[user@]example.com/~user2/path/to/repo.git
ssh: //[user@]example.com/~/path/to/repo.git*

I'm not sure if the author means what he says. He talks of git protocol getting tunneled over SSH.

From my perspective, unless you connect to the git port (agent port), the protocol is not in effect. And SSH is merely an uncompressed file transfer. But as per the author, if we use SSH he says the git protocol is tunneled over it. So is SSH smarter in GIT?

Von C, Thanks for your answer. "Network protocols (HTTP and Git) are generally read-only" Git can be made rw when you run the daemon with --enable=receive-pack.

Following are my concerns.
When they say git protocol is smart, they mean when you execute git clone, Git server agent compresses the data that is sent back to the client, so the clone should be faster. In my use case I'll be setting the Git server in Hongkong and using it on San Jose and other countries as well, So I want to be efficient over network due to latency concerns.

So my question is when I use git clone ssh://user@server/reposloc do I get the benefits of git protocol also? As per O'Reilly author book he means git is tunneled over ssh, then how does git protocol work when I don't have git daemon running on the server.

So using SSh://xyz... does it give both the benefit of ssh and git protocols?

Appreciate your answers in advance.

Answer 1

Update 2010-2014:

Both ssh and https are equivalent, since Git 1.6.6+ (2010) and the implementation of smart http protocol:

You now can use ssh or https for read/write access to your repos.
You can also detect if your remote server supports smart http.
Add the right environment variable if you have to use a proxy.

Q3 2015, as Yousha Aleayoub mentions in the comments:

GitHub "Which remote URL should I use?"

The https:// clone URLs are available on all repositories, public and private.
They are smart, so they will provide you with either read-only or read/write access, depending on your permissions to the repository.

The git-http-backend is the:

simple CGI program to serve the contents of a Git repository to Git clients accessing the repository over http:// and https:// protocols.
The program supports clients fetching using both the smart HTTP protocol and the backwards-compatible dumb HTTP protocol, as well as clients pushing using the smart HTTP protocol.

---

Original answer (July 2010):

From the Pro Git Book:

Probably the most common transport protocol for Git is SSH.
This is because SSH access to servers is already set up in most places — and if it isn’t, it’s easy to do.

SSH is also the only network-based protocol that you can easily read from and write to. The other two network protocols (HTTP and Git) are generally read-only, so even if you have them available for the unwashed masses, you still need SSH for your own write commands.

SSH is also an authenticated network protocol; and because it’s ubiquitous, it’s generally easy to set up and use.

So it is not "smarter" than Git protocol, just a complementary protocol for certain features not addressed by the Git protocol.

The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project.
Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use git:// for read-only access

It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked.

(that is why in my shop, I need to use ssh+git and not just git, even for read access: 9418 is blocked...)