3

Github allows you to clone a public repository in one of two ways. The two methods toggle on the download section of the repository home page:

https://github.com/scrooloose/nerdtree.git

git://github.com/scrooloose/nerdtree.git

The git clone command works with both so why are there two methods available? Can you explain why you would use one over the other?

Milktrader
  • 9,278
  • 12
  • 51
  • 69

4 Answers4

5

The git protocol has the following key problems:

  • The conventional port that the service is run on (9418) may not be accessible behind restrictive firewalls.
  • There is no user authentication, which means that generally the protocol is only used for read-only access.

On the other hand, it's very efficient for fetching from git repositories.

As for HTTPS, GitHub now supports the "smart HTTP" protocol, which means that many of the problems with the "dumb HTTP" protocol that you'll read about (e.g. inefficiency) no longer really apply, although it still won't be as efficient as the git protocol. The chief advantage of using HTTPS to talk to GitHub repositories is it is very unlikely that corporate firewalls will block access to port 443.

(Incidentally, the scope of your question is only about access to public repositories with the git protocol and HTTPS, but I think it's worth pointing out that there are many other considerations for the choice of protocol in the case where you need to authenticate yourself in order to push to a repository.)

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • +1 See also http://stackoverflow.com/questions/4372306/git-push-over-http-not-activating-remote-hooks/4373606#4373606 and the second part of http://stackoverflow.com/questions/2702731/git-fails-when-pushing-commit-to-github/2704113#2704113 – VonC May 21 '11 at 16:26
  • It's odd that the git protocol does not have user authentication. You'd think their mission would be to make the entire repository workflow efficient. Is `https` a good candidate for pushing or are there better ones? (Obviously, I've never pushed) – Milktrader May 21 '11 at 16:32
  • 1
    That's really a different question ;) SSH is the conventional choice for securely pushing to a repository, but some people have trouble setting up SSH key-pairs. For authentication HTTPS is better in usability terms, but smart HTTP is not so ubiquitously supported yet. For pushing to GitHub, however, it's a reasonable choice, I think. – Mark Longair May 21 '11 at 16:46
0

as far as i understand http is deprecated and will be disabled soon. you can get more info here:

https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days

update: looks like i'm wrong. github will disable old ("dumb") http transport. new ("smart") transport will still work.

aav
  • 2,514
  • 1
  • 19
  • 27
  • This is not the case. Http is still available, it is just the particular method used over http. See https://github.com/blog/642-smart-http-support – Cargowire May 21 '11 at 15:33
  • 1
    looks like. even more, it seems that there are two different transports that run over http(s). so, the old one will be disabled. – aav May 21 '11 at 15:35
0

GIT protocol can be more efficient than HTTP for the kind of data transfer involved in cloning a repo... see this post

http://progit.org/2010/03/04/smart-http.html

beer_monk
  • 946
  • 7
  • 7
0

You may be attempting to clone in an environment that has blocked the git protocal/port (9418) via firewalls etc but allows web traffic.

Cargowire
  • 1,488
  • 10
  • 21
  • so you would use the `git` protocol unless it was blocked in which case you have a backup method in `https`? – Milktrader May 21 '11 at 15:39
  • I personally would. As beer_monk described there are also performance considerations as well. In terms of security if you've got write access you'll normally be pushing via ssh (http://help.github.com/remotes/). – Cargowire May 21 '11 at 16:02