Can't figure out how to clone a repository

Question

I am running Ubuntu 20.04. After a computer disaster, I have rebuilt the system, and now need to fetch a fresh copy of my repository. On github, this looks like dddd/PPPP. After changing the directory to ~/AA/BB (where my project root should be) I have loaded git. git init gives me "Reinitialized existing git repository in /home/me/AA/BB" How do I now clone my repository? I can't seem to get the syntax right. I tried: git clone dddd@github.com:PPPP

Cloning into ''PPPP'
dddd@github.com:Permission denied (publickey)
fatal: could not read from remote repository

What am I doing wrong?

Answer 1

I think I correctly generated a new SSH pair - {ssh -Tv git@github.com } generated a ton of output that seemed to be happy. Then I tried to fetch and this happened: {me@Dell:~/Portal/Portal$ sudo git fetch dddd@github.com:PPPP Warning: Permanently added the RSA host key for IP address '140.82.112.4' to the list of known hosts. dddd@github.com: Permission denied (publickey). fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists. d} Any ideas?

Answer 2

Given that you've probably created a new ssh key-pair, you probably do need to update things over on GitHub, as Rafael García said. Follow the listed instructions there. But there's something else important here:

[Running] git init gives me Reinitialized existing git repository in /home/me/AA/BB

This means you already have a clone—or at least, a repository. You probably don't need a new clone.

Remember, git clone means:

• make a new, empty repository (git init in a new, empty directory);
• in the new empty repository, add a remote: a name like origin—the default name is origin but you can pick a different one (don't)—that holds a URL so that you don't have to keep retyping the URL;
• run git fetch against this remote, to get all the commits from some other existing Git repository: whoever answers the Internet-phone-call at the URL is expected to speak Git protocol, and the URL thus refers to their repository, which has commits and their branches;
• once you have all their commits, create remote-tracking names from their branch names: this way you have all of their commits but none of their branches; and finally
• create one local branch, using the same commit hash ID as in one of their branches, so that you have one branch name—such as master or main—that matches your origin/master or origin/main, that your Git made based on their master or main.

So we use git clone to copy a repository. The result is a new repository in which we have our own branches. We don't get their branches: we take their branch names and turn those into our remote-tracking names, like origin/main or whatever. From this point on, we have our repository to work in. We only need to call up their Git, at the saved URL, to get new commits from them (and update our remote-tracking names) or to give new commits to them (with git push, which ends by asking them to set one of their branch names).

After you've updated your ssh key information over on GitHub—which you can test with ssh -Tv git@github.com to see if GitHub recognizes you correctly now—you will almost certainly want to run git fetch, not git clone, so as to update your existing clone by getting any new commits they have, that you don't. Using git fetch has your Git call up their Git, using the stored URL. You can run git fetch origin to be explicit that the name of the remote is origin, but unless you have more than one remote, the name will always be origin (well, unless you did what I said "don't do" above 😀). Git will then figure it out on its own.

Note that git pull is a convenience command. It means: first, run git fetch, then, when that's finished, run a second Git command to incorporate any new commits we just got into my current branch. That second Git command messes with your branches. The first one just downloads their commits, and is therefore safe to run at any time. The second Git command requires being in a proper, ready-to-go state (you can check with git status).

I personally prefer to run git fetch (whenever), and then at my own chosen time, run my own chosen second command, rather than just blindly running git pull. This really is a personal preference thing though: if you prefer to run the two commands back-to-back, without being able to see what you'll be merging or rebasing first, you can use git pull. Lots of people prefer that. It's fine to do it: you just need to know what it means, because when things go wrong, you need to know which second command you chose and how to fix things up at that point. (The fetch step almost never fails—it mostly only breaks if your Internet connection is down—and if it's that step that fails, Git doesn't run the second command at all. So in general, all the failures are from the second command.)

Answer 3

I had the same issue when I factory reset my computer and was trying to clone a private repository. For me, what worked was to create a new SSH key pair and add the public key to my Github account. Please see this website.