Atom: "Do you need to update your remote URL?"

Git newbie. I am working on a Git repository using Atom. I had a hardware failure the other day and have changed computers as a consequence. Managed to re-authorise using SSH and am able to push commits out to the repo from the Git panel in Atom. The strange thing is, that while the Git panel is working, the GitHub panel is saying ‘Repository not found for the remote origin’. Then it asks me ‘do you need to update your remote URL?’ I’m sure I do, and I know exactly what it is, but where is that update made in Atom?

I don’t know that Atom has the ability to change remotes (I’ve never seen it). So you’ll probably have to do it via the command line or an application designed to manipulate repositories such as GitKraken (my preference) or GitHub Desktop.

If you identify the OS you’re on and whether git status from the command line does anything, I can give you more precise details on how to do it purely in commands.

Mac OSX Mojave 10.14.2

Git Status ’ On branch master

Your branch is up to date with ‘origin/master’.

nothing to commit, working tree clean’

As I mentioned, the Git panel in Atom is functioning as expected but the GitHub panel is not connected to the remote branch.

What do you see when you type git remote -v inside the repo in question?

origin (fetch)

origin (push)

I’ve overwritten the company’s name to keep it private.

Git is working fine, it’s simply the issue around Atom’s GitHub panel, which says: ‘do you need to update your remote URL?’ And the answer is: yes - how?

That’s what I’m trying to figure out: do you need to update the remote URL? I’ve never had a repo that had remotes with the format; what if you try to see if the GitHub tab behaves better with that?

And the answer is: yes - how?

Using git remote:

git remote remove origin
git remote add origin
1 Like

Right! Did that and now I get:

origin (fetch)

origin (push)

Atom Editor doesn’t see the repo, though. It seems to be an issue with linking Atom Editor and a remote repository. (Techwriter in room full of engineers here.)

No linking is required. When you have a repository open that has valid remotes, Atom can see and interact with them.

It might be your authorization scheme. If you authorized via SSH, that might be the issue if your repo is private. Atom might be trying to use your git credentials to access the repo, but if you’ve never entered your username and password on your new computer (on the old one, it’s likely that it happened so long ago you don’t remember), then it wouldn’t have anything to work with. Based on reading that page I linked to, I’m even more sure. Atom, being a browser, can communicate via HTTP by default but not SSH. Since the GitHub tab is requesting information about the repo from the site, it’ll go through HTTP to get there and not the SSH connection that you have configured for git.

FYI, I can interact fine with a private repo with SSH authorisation. So Atom can at least do it.

I chose this because git on Ubuntu doesn’t seem to store HTTPS credentials longer than 15 minutes, but it does for SSH.

1 Like

What happens if you

  1. Make a new personal private repo on GitHub
  2. Click Clone or download -> Use SSH -> :clipboard: (copy)
  3. Run git clone <paste here>
  4. Try it with Atom / on the command line

I believe the only thing I did to set up the key was following these instructions

I think that hits the nail on the head. I did manage to work out how to create the auth. key for this replacement Mac yesterday, but I couldn’t follow the instructions on creating a passphrase (not least because in the Git documentation on that topic, what a passphrase ought to consist of is not even mentioned). And, as you say, the remote repository is currently set to Private (although that might be changed in future.) And, thanks for the tips, your posts are a wealth of information! (The fact that Atom is a browser, although it’s now obvious, had actually escaped me up until this point.)

I did that too, but I couldn’t follow the section under ‘adding or changing a passphrase’. That section seems to assume that the reader knows what a passphrase is, and already has one. And also it doesn’t mention the specific system build I’m using (namely Mojave). And as Scholar points out above, that is likely why I can connect via Git, but Atom can’t connect to GitHub.

So today. I can’t push to Git using Atom. I go back to the immensely confusing, difficult and cryptic documetation on Authenticating to Git, and get to the point of ‘testing SSH connection’, having generated a token yesterday. So following the instructions in that section, I see:

‘You’ve successfully authenticated, but GitHub does not provide shell access’.

I don’t know why I would want ‘shell access’ or what it does, or indeed if I am now ‘authenticated’ to the remote repo, however I do know that I can’t seem to connect.

I been shown by one of the devs here, that when you look at the settings in the control panel for a repository, you can either connect via SSH or via HTTPS - there’s a toggle which allows you to select either https or ssh. So since I did that command yesterday to re-connect via HTTPS, then I am no longer connecting via SSH. So

That is what you see when you’re connected via SSH, or so it now seems to me.

Yes, that’s SSH. I did not set up a pass phrase on my own, so I can’t speak for how that works.

I can repeat however, that without the pass phrase everything is working perfectly with SSH (* except publishing Atom packages, but that doesn’t sound relevant).

So I have no idea why it works for me and not you, but I wouldn’t be blaming SSH.

1 Like

Not blaming SSH - what I did was set up an SSH connection, and then used a command to change it to an HTTPS connection. You can see in the screenshot, you can either connect via ssh or by https:


I had set up to connect via SSH, but when I executed the command ‘remove origin’ and replaced it with ‘https://…’ then it changed my connection profile, or whatever you call it. Just trying to figure out how to retrace my steps so as to restore the connection via SSH.

The shell is the program that you interact with to get the computer to do things. It knows how to find and display your files and send instructions to other programs. When you pull up a command line window, that’s your shell. bash, zsh, cmd, and PowerShell are the most common examples you’ll see.

That is what you see when you’re connected via SSH, or so it now seems to me.

Yeah, it is. I brought it up because I can’t personally vouch that the GitHub tab works with SSH, but @Aerijo says that it does.

I have a general idea of what shell access is, but I don’t understand the relevance in that context.

I’ve now confused myself by running the ‘Clone with SSH command’ on the GitHub repo (trying to work out how to re-establish this authentication path) which of course made new copies of all the files from the remote to my local directory. So now if I check Git Status, it lists all the files in the directory as '‘Changes to be committed’. I suppose if I do that, then all it will do is overwrite all the copies in my local directory with what is in the remote directory. Should I go ahead and do that? (Sorry for asking such basic questions.)

actually I now see that ‘clone’ has created a copy of the whole directory inside a sub-directory. I really should reverse that or delete it. Is that what ‘checkout’ is for - could I use Atom to delete the directory and then ‘checkout’ in Git?

All you should have to do is use git remote remove origin again and then re-add it with the proper address (I legitimately thought that they were interchangeable until this thread; now I know more and will be better able to help people in the future).

Don’t commit willy-nilly, and don’t commit in a repo where you don’t understand the extent of the changes that have been made. If you did commit and then push, it would have the potential to cause disruption in your remote repo and distress your colleagues.

There is no reason why you can’t delete the directory you just cloned from Finder. You haven’t done anything in it, so that whole folder is safe to remove. It doesn’t contain any work that isn’t already backed up on GitHub.

git checkout is for looking at specific commits or branches. Every commit is a snapshot. You can think of them as a series of folders, frozen in time, each containing a different version of your work. git checkout lets you go back or sideways in the timeline to see how things were last year or work on new features on different branches so that you can maintain an orderly and hygienic process of building in new code/chapters/whatever.

I happily do most of my git stuff on the command line, but for checkouts I think GitKraken (linked above) is essential for anyone who didn’t grow up on git. It will give you a great visual representation of your repo that is easy to navigate and–most importantly–you don’t have to remember the commands or type random alphanumeric sequences to jump around. You can do so using things that humans are better at parsing, like dates and “it was when so-and-so made changes to whatever file”.

Right! Did that, and then ‘git reset HEAD’ with advice from one of the staff here - all OK now.

I’ve done that too, but the original issue of 'repository not found for the remote origin remains. I think it might be related to the issue of the fact that the repo is set to ‘private’. But it’s not a show-stopper as I can push to it.

Thanks, I will check it out. And thanks again for your input, it’s truly appreciated.