Received password notice and created token, but do not receive prompt and git repo clone fails

Not new to Git, but new to setting up the token. I received the email for deprecating passwords. So I went ahead and created the token and updated my security settings for repo. In Git, when I go into clone the new repo.git, it goes to logon via the user/pw web interface and then fails. It does not prompt me for the token.

$ git clone https://github.com/name/repo.git
Cloning into ‘repo’…
Logon failed, use ctrl+c to cancel basic credential prompt.
remote: Repository not found.
fatal: repository ‘https://github.com/name/repo.git/’ not found

Any suggestions are much appreciated.

Don’t include the trailing .git in the repositories’ URLs, or in your remotes.

I believe the trailing .git is correct in the url.
if your credentials are not valid/you do not have permissions on a specific repository you are likely to get a not found response rather than no permissions type response.
If you are having difficulty, clearing cached credentials normally resolves people problems. On re-entering details remember to type ‘token’ values when promoted for ‘password’

There are two different errors at stake here, one with the credentials updates recently enforced by GitHub, and the second pertaining to the message:

fatal: repository ‘https://github.com/name/repo.git/’ not found

The trailing .git is one of the most common source of problems in Git operations on GitHub via HTTP(S) protocol. GitHub fails to find the repository due to the extra .git in the URL.

As for the credentials update, I had the same problem described by @bmalin77, but unfortunately can’t recall all the steps I took to solve the problem (under Win 10). I remember that after updating my credentials on my GH account, and creating the token, I had copied it somewhere, and also had to remove the old one from some Git settings files in my user folder.

But I also reverted to Git’s native credential manager, because I had shifted to use Microsoft’s credential manager a couple of years ago. I don’t know for sure if changing the credential manager settings helped to solve the problem, but it’s a step worth considering (also, the problems with the old credentials manager that ships with Git are now solved, so it’s safe to use).

You’re right, I tried cloning with and without the .git part, and both worked. But I know for sure that the trailing .git can cause problems in some contexts. It’s better to just leave it out, replicating the repository URL shown in the browser’s address bar.

So, why is GitHub reporting the repository as “not found”? is it just because the login failed?

Probably on servers that aren’t set up to handle it. I just checked, the HTTPS clone URL GitHub provides on the repository page includes the .git ending, so it should be safe (in fact, expected) to include it.

Yes. I’ve seen that in other contexts, GitHub usually returns 404 (not 403) for user data you’re not authorized to see. That has the advantage of not revealing if that data even exists to an unauthorized user.

True, and I used to include that URL in project’s instructions, until some users started reporting that some operations failed until they removed the trailing .git. Maybe it was an OS specific problem, or related to a Git frontend, I don’t recall the nature of the problem but I shall look it up in the closed Issues of that project. Anyhow, it’s also safe to omit it — I never include it in my remotes and didn’t face any problems.

Good point!

1 Like

OK, I’ve managed to find the original Issue were end users reported problems using URLs with the trailing .git:

User @Naheulf reported that attempts to add a remote failed when including the trailing .git in the repository URL:

$ git remote add upstream https://github.com/fantaisie-software/purebasic.git
fatal: not a git repository (or any of the parent directories): .git

I remember doing some local tests that confirmed the problem, but some time has elapsed since so I don’t recall the details, just that I stopped including the trailing part ever since.

Unless that reported error was being caused by some other issue (e.g. credentials failure, like here, but I doubt it since it was resolved without tweaking credentials), it’s worth looking into it since I see a lot of posts here reporting problems on failed Git operations, many of them displaying the use of URLs with trailing .git. If this is a cause of errors (even if on some OSs, Git frontends, etc.) it’s worth digging into it.