Git: says origin already exists on "NEW" (init) repository, using shell but installed Github for Windows

Question

I installed Git for Windows, although I am using the shell not the Windows interface.

If I do a git init, and then try and do a

 git remote add origin [email protected]:someuser/testme.git

I get the following error

 fatal: remote origin already exists.

So I do a

 git remote -v

and it returns the following

origin
upstream

So it appears its there but has no URL set, I don't understand why it's there?

If I do a

 git remote rm origin

it produces this

 error: Could not remove config section 'remote.origin'

It says that it can't remove the remote.origin config section; I checked the .gitconfig under my home directory and I don't see anything.

Anyway I was able to remedy this by using

 git remote set-url origin [email protected]:someuser/testme.git

But I am getting confused as I have used Git before and this never happened.

Could this be something to do with Git for Windows?

Togo

you are most probably in a folder which already was a git repository. git init will have told you if it re-initialized the repo, in which case nothing is changed. In such a situation, there might naturally be remotes which already existed in the repo – Stepp

I wasn't it was a completely clean directory.... I even moved to another directory that had no relation to this one and created a new init and same again – Togo

then you have some problem with your whole environment (this could be a few different things, so it's difficult to tell without having access). Try rebooting and see if the behavior persists. this might be caused by some shell environment variables being set. – Stepp

No, I tried rebooting and the same issue. – Togo

Make sure there are no hidden files you aren't aware of. Git stores configuration settings in .git, and if you are in a sub folder of a folder that is a git repository, that could be causing your issues. – Lind

Answer 1

I'm the developer who put this in. Here's why I added this to the system gitconfig, it's pretty useful!

## Because of this change, git fetch knows about PRs
git fetch

## Now, I can merge PRs by number
git merge origin/pr/24

## See changes from PR #53
git diff master...origin/pr/53

## Get the commit log from PR #25
git log origin/pr/25

Unfortunately, this does have the consequence that the origin remote always exists, even when it doesn't.

Workaround

Whenever you see git remote add origin https://..., instead:

git remote set-url origin https://...

Affiche

@Paul Does this mean the manual setup outlined in Checking out Pull Requests locally at GitHub Help is no longer necessary with this new feature? (I tried git checkout pr/999 without doing anything to my .git/config and it worked.) – Sumer

After reading Chad's answer and its comments, I went to check my ~\AppData\Local\GitHub\PortableGit_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\etc\gitconfig and, sure enough, the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* was there. So, to answer my own question: yes, newer versions of GHfW come with git checkout pr/999 functionality baked in at the system level, so it is no longer necessary to do any manual configuration to checkout pull requests locally. – Sumer

I just loved the first line :) – Witham

Answer 2

I've been running into the same issue, and I think I've figured it out finally. GitHub for windows installs a version of PortableGit in /Users/<username>/AppData/GitHub. In the PortableGit directory, under /etc, there's a gitconfig file. This is the system config. It defines "origin" and "upstream", presumably with defaults that are meaningful to GitHub.

I can't say for sure, but I started noticing this problem in the latest few updates of the GitHub for Windows client. Sadly, the release notes don't point to anything probative and the Windows client isn't open-source so it's hard to tell.

I've sent a message to their support address, so I'll update here if I hear anything back.

Edit: GitHub support responded saying this is a known issue and will be fixed soon.

Trelliswork

did they solve it yet? I see the Windows client is still version 1.0, but I already have that.... – African

my path was C:\Users\[UserName]\AppData\Local\GitHub\PortableGit_[long string here]\etc – Westfahl

As of Aug 20, I don't see that this fix has made it into the Windows Github client yet. You may be able to take Yaniv's advice and simply remove the origin section in the global gitignore. – Trelliswork

This was the clue I needed. I had the same problem as the OP when using the powershell window opened from GitHub for Windows. I instead opened another normal command prompt window and everything worked. Its the GitHub integration that was the problem. (btw - I was pushing to BitBucket) – Chromatin

Answer 3

I simply deleted the origin section in %appdata%/Local/GitHub/PortableGit_.../etc/gitconfig and everything went back to normal - new repos act accordingly when I add remote origin to them, since they have none when they are created.

There might be side effects for this deletion, but so far I haven't ran into any trouble.

Doxy

If you do this, many of the "Open in Desktop" buttons on github.com will do Weird Things – Affiche

I only work with the command line so I guess that is why I never ran into this. I guess my solution can be classified as a temporary workaround until such a time that github will deal with this. – Doxy

This solved it for me and So far i haven't had any problems with github and their clone to desktop button – Jackpot