> in saying that git:// is faster than https://. In fact, we have some > reports and testing that https:// can be significantly faster (due to other > reasons). Can you elaborate on the other reasons? It occurs to me that there might be cases in which each way works better.
Those aren't protocol based, they're deployment based.
For example, for the https we have a fast cache, for the git:// stuff it reloads things all the time. The git daemon also has no proper way to limit or handle concurrency,so tends to get hit much harder there where the http cache can take care of much of that. Things like that, not the protocol itself.
From an experience about 3½ years ago[1], I drew a conclusion (which may have been erroneous, or may have changed in newer git releases) that the http protocol handler was not as bidirectional: the client was less able to negotiate with the server exactly which objects it already had and which were wanted, leaving the server to send a needlessly large mass of stuff by default, whereas git-over-ssh was able to negotiate a tiny minimal pack file to transfer.
Yes, this used to be the case, and is the reason behind the original recommendation. It's what they call the "dumb HTTP protocol" in the docs. This is not the case when you use git-http-backend, which is the change we made a few months back.