If you’re having trouble cloning a repository, check these common errors.
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 «Managing your personal access tokens.»
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'
Есть репозиторий в gitlab. Двухфакторная авторизация отключена, ssh не используется.
Команда git clone lalala.la:77/la/lala.git под linux приводит к успешному склонированию проекта, а под windows к ошибке
remote: HTTP Basic: Access denied
fatal: Authentication failed for ‘httр://lalala.la:77/la/lala.git’
git did not exit cleanly (exit code 128) (7219 ms @ 01.04.2017 21:59:07)
И под линуксом, и под виндой ввожу одни и те же логины и пароли, пробовал на трёх разных машинах и на двух разных пользователях.
В чем может быть проблема, куда смотреть?
Заранее спасибо за любую подсказку.
_______________________________
UPD
Не работает только если пользоваться стандартным окошком ввода логина и пароля, если при его появлении нажать на «отмена» и ввести логин и пароль в командной строке, то все срабатывает.
_______________________________
UPD РЕШЕНИЕ
Проблема все же на стороне tortorize git.
Решить можно так:
Нужно переустановить git на этот раз в процессе установки отключив
«enable git credential manager»
После этого нужно переустановить tortorise, в процессе выбрав credital helper : none
И все, больше проблем при выгрузке репозитория не возникнет.
Trying to access private corporate tfs.
They gave me access by giving appropriate rights to windows user (domain\login).
I’m fine with accessing web interface of tfs, browse repository and stuff.
But when I try to run
git clone https://tfs.somehostname.com/tfs/somefolder/_git/therepository
It fails with
Cloning into 'therepository'...
fatal: Authentication failed for 'https://tfs.somehostname.com/tfs/somefolder/_git/therepository/'
Tried with home pc without corporate network stuff — same error.
Tried in PowerShell, Git Bash, Clone via VisualStudio — same error.
SSH is closed (gave request timeout).
Web & Git both ask for credentials once (tried deleting in Credentials Manager — asks again, after submitting web is fine, git fails)
Corporate helper tried to help, but all he gave is tfs logs.
He says, my username doesn’t come with requests (tracked by syncing my attempts timestamps with logs).
2018-07-19 07:04:00 SOMEIP GET /tfs/SOMEFOLDER/_git/REPOSITORY/info/refs service=git-upload-pack 443 - ANOTHERIP git/2.12.2+(Microsoft+Windows+NT+6.3.9600.0;+Win32NT+x64)+CLR/4.0.30319+VS15/15.0.0 - 401 2 5 62
2018-07-19 07:23:00 SOMEIP GET /tfs/SOMEFOLDER/_git/REPOSITORY/info/refs service=git-upload-pack 443 - ANOTHERIP git/2.18.0.windows.1 - 401 2 5 62
2018-07-19 07:23:00 SOMEIP GET /tfs/SOMEFOLDER/_git/REPOSITORY/info/refs service=git-upload-pack 443 - ANOTHERIP git/2.18.0.windows.1 - 401 1 3221225581 187
while others include it
2018-07-19 05:44:27 SOMEIP GET /tfs/SOMEFOLDER/_git/REPOSITORY/info/refs service=git-upload-pack 443 DOMAIN\LOGIN ANOTHERIP git/2.12.2+(Microsoft+Windows+NT+6.1.7601+Service+Pack+1;+Win32NT+x64)+CLR/4.0.30319+VS15/15.0.0 - 200 0 0 265
I have been trying to clone a local Git repository for about an hour now. The repository is on a Windows 7 server, and I am trying to make a clone right next to it. My workflow is to clone the repository, make some changes, and test. If all is good, I pull the changes back into the original repository and delete the clone.
I am using Git Bash (part of Tortoise Git). The repository is on a mapped network drive. I was having some issues cloning because of the drive, so I read this:
git clone from another directory
I then did the following:
spearsc@BB-DIGI-SPEARSC MINGW64 /r/nasenv (master)
$ git clone . /r/nasenv_copy
Cloning into 'R:/nasenv_copy'...
done.
error: internal error: refs/remotes/origin/master is not a valid packed reference!
fatal: update_ref failed for ref 'HEAD': cannot update ref 'refs/heads/master': trying to write ref 'refs/heads/master' with nonexistent object 1fa512cca95695979f35515f1ea69c391d214544
fatal: The remote end hung up unexpectedly
The resulting repo is empty except for a .git folder. From past experience, I thought the issue was the mapped drive (in this case R).
I tried the following:
spearsc@BB-DIGI-SPEARSC MINGW64 /r/nasenv (master)
$ git clone . file://r:\nasenv_copy
fatal: could not create leading directories of 'file://r:nasenv_copy': Invalid argument
spearsc@BB-DIGI-SPEARSC MINGW64 /r/nasenv (master)
$ git clone . file://r:/nasenv_copy
fatal: could not create leading directories of 'file://r:/nasenv_copy': Invalid argument
spearsc@BB-DIGI-SPEARSC MINGW64 /r/nasenv (master)
$ git clone . file://r/nasenv_copy
fatal: could not create leading directories of 'file://r/nasenv_copy': Invalid argument
spearsc@BB-DIGI-SPEARSC MINGW64 /r/nasenv (master)
$ git clone . file://R:/nasenv_copy
fatal: could not create leading directories of 'file://R:/nasenv_copy': Invalid argument
None of these work. This is really frustrating because I did do this last week. I’m not sure if I just forgot or if a change in the main repo is causing this.
git clone gituser@<server>:myRepo.git doesn’t work, fails with the error message:
fatal: ''myRepo.git'' does not appear to be a git repository
Background:
We have a Windows 7 machine set up with Git Bash and Bitvise WinSSHd (on C:). The SSH server is set up to use <git dir>/bin/sh.exe --login as the shell, with the home directory set to /a/. I can SSH onto the server just fine, and it drops me into the Git Bash shell as expected, starting in the /a/ directory.
I have a bare repository at /a/myRepo.git (on the A: disk) which does everything it should, as long as we’re doing it locally. I can git clone /a/myRepo.git, work on it, push and pull, no problems as long as it’s local (or «local» over SSH). Furthermore, we set up the A: disk as a shared folder, and I can clone, push, and pull from a local network machine using \\<server>\myRepo.git.
When I try to clone remotely, however, I cannot figure out what combination of options will allow it to work: The obvious clone string doesn’t work, putting an absolute pathname in either *nix-converted format (/a/myRepo.git and A:/myRepo.git) or Windows format (A:\\myRepo.git) fails with the same error, the permissions on the directory are set up to allow all users, and I’ve set git config core.sharedRepository all on the serving machine as well.
I had a suspicion of Git Bash’s remapping of Windows drive letters into /<letter> format, but I tried creating another bare repository on C: and it gives me the same error message.