Git error command git clone

HTTPS cloning errors

There are a few common errors when using HTTPS with Git. These errors usually indicate you have an old version of Git, or you don’t have access to the repository.

Here’s an example of an HTTPS error you might receive:

> error: The requested URL returned error: 401 while accessing
> https://github.com/USER/REPO.git/info/refs?service=git-receive-pack
> fatal: HTTP request failed

> Error: The requested URL returned error: 403 while accessing
> https://github.com/USER/REPO.git/info/refs
> fatal: HTTP request failed

> Error: https://github.com/USER/REPO.git/info/refs not found: did you run git
> update-server-info on the server?

Check your Git version

There’s no minimum Git version necessary to interact with GitHub, but we’ve found version 1.7.10 to be a comfortable stable version that’s available on many platforms. You can always download the latest version on the Git website.

Ensure the remote is correct

The repository you’re trying to fetch must exist on GitHub.com, and the URL is case-sensitive.

You can find the URL of the local repository by opening the command line and
typing git remote -v:

$ git remote -v
# View existing remotes
> origin  https://github.com/ghost/reactivecocoa.git (fetch)
> origin  https://github.com/ghost/reactivecocoa.git (push)

$ git remote set-url origin https://github.com/ghost/ReactiveCocoa.git
# Change the 'origin' remote's URL

$ git remote -v
# Verify new remote URL
> origin  https://github.com/ghost/ReactiveCocoa.git (fetch)
> origin  https://github.com/ghost/ReactiveCocoa.git (push)

Alternatively, you can change the URL through our
GitHub Desktop application.

Provide an access token

To access GitHub, you must authenticate with a personal access token instead of your password. For more information, see «Creating a personal access token.»

If you are accessing an organization that uses SAML SSO and you are using a personal access token (classic), you must also authorize your personal access token to access the organization before you authenticate. For more information, see «About authentication with SAML single sign-on» and «Authorizing a personal access token for use with SAML single sign-on.»

Check your permissions

When prompted for a username and password, make sure you use an account that has access to the repository.

Tip: If you don’t want to enter your credentials every time you interact with the remote repository, you can turn on credential caching. If you are already using credential caching, please make sure that your computer has the correct credentials cached. Incorrect or out of date credentials will cause authentication to fail.

Use SSH instead

If you’ve previously set up SSH keys, you can use the SSH clone URL instead of HTTPS. For more information, see «About remote repositories.»

Error: Repository not found

If you see this error when cloning a repository, it means that the repository does not exist or you do not have permission to access it. There are a few solutions to this error, depending on the cause.

Check your spelling

Typos happen, and repository names are case-sensitive. If you try to clone git@github.com:user/repo.git, but the repository is really named User/Repo you will receive this error.

To avoid this error, when cloning, always copy and paste the clone URL from the repository’s page. For more information, see «Cloning a repository.»

To update the remote on an existing repository, see «Managing remote repositories».

Checking your permissions

If you are trying to clone a private repository but do not have permission to view the repository, you will receive this error.

Make sure that you have access to the repository in one of these ways:

• The owner of the repository
• A collaborator on the repository
• A member of a team that has access to the repository (if the repository belongs to an organization)

Check your SSH access

In rare circumstances, you may not have the proper SSH access to a repository.

You should ensure that the SSH key you are using is attached to your personal account on GitHub. You can check this by typing
the following into the command line:

$ ssh -T git@github.com
> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.

If the repository belongs to an organization and you’re using an SSH key generated by an OAuth App, OAuth App access may have been restricted by an organization owner. For more information, see «About OAuth App access restrictions.»

For more information, see Adding a new SSH key to your GitHub account.

Check that the repository really exists

If all else fails, make sure that the repository really exists on GitHub.com!
If you’re trying to push to a repository that doesn’t exist, you’ll get this error.

Error: Remote HEAD refers to nonexistent ref, unable to checkout

This error occurs if the default branch of a repository has been deleted on GitHub.com.

Detecting this error is simple; Git will warn you when you try to clone the repository:

$ git clone https://github.com/USER/REPO.git
# Clone a repo
> Cloning into 'repo'...
> remote: Counting objects: 66179, done.
> remote: Compressing objects: 100% (15587/15587), done.
> remote: Total 66179 (delta 46985), reused 65596 (delta 46402)
> Receiving objects: 100% (66179/66179), 51.66 MiB | 667 KiB/s, done.
> Resolving deltas: 100% (46985/46985), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.

To fix the error, you’ll need to be an administrator of the repository on GitHub.com.
You’ll want to change the default branch of the repository.

After that, you can get a list of all the available branches from the command line:

$ git branch -a
# Lists ALL the branches
>   remotes/origin/awesome
>   remotes/origin/more-work
>   remotes/origin/new-main

Then, you can just switch to your new branch:

$ git checkout new-main
# Create and checkout a tracking branch
> Branch new-main set up to track remote branch new-main from origin.
> Switched to a new branch 'new-main'

Run git clone http://github.com/schacon/ticgit.git instead.

That is, replace git:// with http://. This should work.

For an encrypted connection—which is generally a good thing because the data you receive probably cannot be modified in transit by any malicious third party—you can try using https://. Thanks to Mitch for pointing this out. This worked for me, though it was considerably slower (it took almost half a minute instead of less than two seconds). Your mileage may vary.

Explanation follows… (But if you want, you can stop reading here and just use that command.)

Your corporate (or school) network might be preventing you from accessing the Git server.

On my Internet connection, I’ve checked to see if the IP address 204.232.175.90 has a server accepting incoming connections on port 9418. (After all, that is what it has to do, not what you have to do.) It does, though at that time (i.e., before I tried cloning the repo myself) it was not clear to me if what’s running on that port is actually a Git server:

ek@Kip:~$ sudo nmap -sS -sV -p9418 204.232.175.90
[sudo] password for ek:

Starting Nmap 6.00 ( http://nmap.org ) at 2013-08-16 09:25 EDT
Nmap scan report for github.com (204.232.175.90)
Host is up (0.046s latency).
PORT     STATE SERVICE VERSION
9418/tcp open  domain  ISC BIND   Email support

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.82 seconds

Even if that had been something other than a Git server, you should still not have gotten «connection refused». If you get the same error when you try again, something is blocking your ability to connect to that server. If possible, I recommend consulting your network administrator. After all, you should ideally be able to access that server. And most network administrators are probably not going to have a problem with you accessing Git repositories.

However, there is an easy workaround.

For people in your situation, and other situations where only HTTP access is possible (for example, people whose only access to the Internet is through an HTTP proxy), Git provides the ability to access repositories with HTTP (i.e., via the web)!

I don’t mean that you’d browse the web to clone the repository. The git command is itself capable of connecting over HTTP, as an alternative to using Git’s own application layer protocol.

To do this, replace git:// with http:// in the URL given to the git command.

From your perspective as a user, this works exactly the same way. The only difference you may notice (besides that this way should work!) is that it may be slower, since HTTP is less well-suited to accessing Git repositories than Git’s own protocol.

That can be an issue over time, or for huge repositories. That’s why I recommend contacting your network administrator. But in this case, there should be no problems; the repository appears small. (Even if it were large, increased wait times are sometimes acceptable. It’s when you have to transfer a lot of data, many times per day, that it can become burdensome to your workflow.)

It’s possible for a Git server not to offer HTTP access, but in practice that is rare, and I have tested this one, and it does provide it, and I was able to clone the repository:

ek@Kip:~/src$ git clone http://github.com/schacon/ticgit.git
Cloning into 'ticgit'...
remote: Counting objects: 1857, done.
remote: Compressing objects: 100% (1022/1022), done.
remote: Total 1857 (delta 781), reused 1787 (delta 735)
Receiving objects: 100% (1857/1857), 374.78 KiB | 702 KiB/s, done.
Resolving deltas: 100% (781/781), done.
ek@Kip:~/src$ ls ticgit                # you don't have to run this
bin       lib          LICENSE_MIT  Rakefile    spec               TODO
examples  LICENSE_GPL  note         README.mkd  ticgit-ng.gemspec
ek@Kip:~/src$ du -sh ticgit            # you don't have to run this
844K    ticgit

I also did it with git:// and got the same results. HTTP access works fine for this repository.

As stated above, https:// worked fine for me too, though it was much slower. But I think a lot of the time may have been in negotiating the connection—I don’t expect that it would necessarily be much slower than http:// for a large repository.