Error remote upstream already exists

Git Remote Add Upstream – fatal: remote upstream already exists

While attempting to add https://github.com/alanrenouf/vCheck-vSphere as an upstream something went awry and I was constantly presented with the error:

fatal: remote upstream already exists

OK, but when I tried to fetch the upstream it failed with:

fatal: ‘upstream’ does not appear to be a git repository

Being new to git this took a little while to figure out, but I thought I’d document it in case it would be helpful for someone else.

Inside a repository you can check your remote repositories configured with:

From which I could see that my fork was correctly configured with a URL, but not the upstream

This can be corrected with:

and confirmed with again:

Subsequently, I was able to fetch the upstream:

6 thoughts on “Git Remote Add Upstream – fatal: remote upstream already exists”

Thanks for posting this fix! I’ve been using GitHub for Windows and this seemingly undocumented issue has been annoying the hell out of me.

You are welcome. Glad it was of some use 🙂

Источник

How to fix ‘fatal: remote origin already exists’ Git error

Learning objective

What is the ‘fatal: remote origin already exists’ error?

fatal: remote origin already exists is a common Git error that occurs when you clone a repository from GitHub, or an external remote repository, into your local machine and then try to update the pointing origin URL to your own repository.

In the context of Kubernetes, the error can occur when you configure orchestrations to include Git repositories. For example, by using: git remote add origin [url].gits

fatal: remote origin already exists is caused by the cloned repository already having a URL configured. Specifically, a URL that leads to the original profile where the repository source is.

What is a remote origin in Git?

remote origin , as the name implies, is the place where code is stored remotely. It is the centralized server or zone where everyone pushes code to and pulls code from.

Remote repositories are versions of your project hosted on Git-compatible platforms such as GitHub, Bitbucket, GitLab, and Assembla. origin is the standard and generic handle that is used to associate the host site’s URL.

For example, you can have an alternative remote URL called dev , which then becomes the handle for a separate repository but for the same code.

When you run git remote -v , you will get a list of handles and associated URLs. So if you have different handlers for the same remote, the console output could look something like this:

This means that you can run the following command: git push dev master

The changes made will get pushed up to the master branch at the URL associated with dev and not origin .

Detect and fix errors 5x faster

Komodor monitors your entire K8s stack, identifies issues, and uncovers their root cause.

Resolving ‘fatal: remote origin already exists’

For most development environments, origin is the default handler used. Here are 3 ways to resolve fatal: remote origin already exists .

1. Remove the Existing Remote

remote refers to the hosted repository. origin is the pointer to where that remote is. Most of the time, origin is the only pointer there is on a local repository.

If you want to change the pointing URL attached to origin , you can remove the existing origin and then add it back in again with the correct URL.
To remove your handler, use the remove command on remote , followed by the handler name – which, in our case, is origin .
Here is an example: git remote remove origin

To check that handler is deleted properly, run the following: git remote -v

You will either get an empty list, or you will get a list of remote handlers that are currently attached to the project with origin removed from the list.
Now you can run git remote add origin [url].git without encountering the fatal: remote origin already exists error.

2. Update the Existing Remote’s URL

You are not always required to remove the origin handler from remote . An alternative way to solve fatal: remote origin already exists is to update the handler’s pointing URL.

To do this, you can use the set-url command, followed by the handler name (which is origin in our case) and the new URL.

Here is the syntax for updating an existing origin URL: git remote set-url origin [new-url]

Once this is completed, you can now push and pull code from the newly configured Git repository location.

3. Rename the Existing Remote

Alternatively, you can rename origin to something else. This means that instead of deleting the handler’s pointing URL to make room for the new one, you can rename it and keep the original details.

To do this, use the rename command on: remote .

For example, if you want to rename origin to dev , you can use the following command: git remote rename origin dev

Now when you run git remote -v , you will get dev as the handler instead of origin .

This will give you room to add a new origin to the list of attached handlers. So when you run git remote add origin [url].git , you will no longer get the fatal: remote origin already exists error prompt.

How to prevent ‘fatal: remote origin already exists’

To prevent fatal: remote origin already exists error from occurring, you can check if the origin handler already exists. If it does not, running the git add remote origin command should not produce this issue.

The most important thing to note here is that origin is only a handler’s short name. It is a reference to the URL, which is where the actual remote repository is hosted.

The handler origin just happens to be the standardized default. This is what makes fatal: remote origin already exists so common. The error itself can occur against any handler, provided that it has the same placeholder name.

To check if origin even exists, run git remote -v to get a list of current remote handlers and the associated URLs.

If origin exists, you can do one of the following:

• remove origin from the remote list via remove command, like so: git remote remove origin
• update origin pointing URL with set-url , like so: git remote set-url origin [new-url]
• rename the existing origin handler to something else via rename command: git remote rename origin [new-name]

K8s troubleshooting with Komodor

We hope that the guide above helps you better understand the troubleshooting steps you need to take in order to fix the fatal: remote origin already exists error.

Keep in mind that this is just one of many Git errors that can pop up in your k8s logs and cause the system to fail. Due to the complex and distributed nature of k8s,
the search for the root cause of each such failure can be stressful, disorienting and time-consuming.

This is why we created Komodor, which acts as a single source of truth (SSOT) to streamline and shorten your k8s troubleshooting processes. Among other features, it offers:

Источник

Git error — Fatal: remote origin already exists and how to fix it

«Remote origin already exists» error

The error `fatal: remote origin already exists` is caused when you attempt to create a link to a remote repository called “origin” when a remote link with that name is already configured.

The solution is to update the URL of the remote repository with the name “origin” to the URL of the remote repository you want to add, instead of trying to create a new remote repository with that name.

You can do that with this command:

‍
It’s possible to inadvertently configure your local repository wrong if you don’t totally get what the commands that you’re running mean, or if you cloned a repository that already has a remote with the name “origin” configured.

To help you avoid making this mistake again, let’s unpack the concept of remote repositories a little. This error is usually caused by misunderstanding one of several things: what a remote repository is, how the `remote` command works, or more specifically what “origin” part of these commands means.

What is a remote repository?

To understand what a remote repository is, it’s important to first understand that Git stores and operates on your data in your local file system. In fact, Git is referred to as a distributed version control system because the source code is stored, or distributed, locally across any number of computers and servers. This is different from many of the source control tools that preceded Git.

Those tools were known as centralized version control systems (SVN or Subversion are the most well known examples), and they only operated on data hosted on a server by uploading changes in real time.

This meant that everybody always had access to the same data, because they were all working from the same server, but changes were slow to update and relied on a stable internet connection at all times.

Because all work stored in a Git repository lives in your local file system, source control operations are blazing fast and don’t require an internet connection, since you don’t upload each change to a server as it happens. The tradeoff is that your code isn’t easily accessible to others, so you need to regularly upload your changes to a server in order for other people to access them.

This is where remote repositories, or remotes, come in. A remote repository is a Git repository that lives on a server and is set up to be a mirror of your local work. Every time you run the `git push` command, you push your latest changes into that remote repository. Then, when somebody pulls from that remote repository, they receive your changes and end up with the same code you have.

This means that your code usually lives in multiple places — in your local Git repository, in the remote one living on the server (GitHub is the most well known server), and in the file system of anybody else who has downloaded your work from the remote repository into a local repository of their own.

In a nutshell, a remote repository is where you upload your locally stored changes so that others can access them.

Now that we’ve covered what a remote repository is and why it’s necessary, it’s time to talk about how you can attach one to your local repository. Usually, this isn’t something that happens automatically — you need to configure remotes by hand

Git’s `remote` tool provides a number of commands to configure remotes: add, remove, rename, etc. You can read the full documentation here, but for the purposes of solving the error this article is about, we are going to be most concerned with “add”, “remove”, and “reset-url”.

Let’s cover the few specific use-cases relevant to us briefly below:

git remote add is going to be the most commonly used command. This is how you can attach a remote to your repository. It associates the “url” parameter with the “name” you pass in. Looks like this, as you probably already know:

git remote remove is pretty self-explanatory, and is also used frequently. If you don’t want to have a particular remote attached to your repository, just pass its name to this command and that remote will be completely removed. It won’t persist in history, caching or anywhere else:

In theory, you could remove the `origin` remote and then re-add it, but instead of doing that in two steps, you can actually knock it out in just one with the `set-url` command that I showed you at the top of this article. In one step, this command will update the URL of a repository for the given name you pass in.

Just for an example, if we were to list the remotes with `git remote —verbose` before and after running this command, they might look like this:

Let’s run the `set-url` command:

‍
And looking at the list again:

“origin” is a convention, not a part of the `git remote` command

It’s worth noting that using “origin” for the name of your default remote repository is simply a convention — you could name your default remote “cheese” for all the difference it would make.

It’s frustrating, because this convention is actually the primary source of remote naming errors. At first glance it’s not obvious whether “origin” is part of the `git remote` command or just a parameter, a misconception that is further supported by the wording of the Git error: it’s not obvious that “origin” is a parameter, and not a part of the failing command.

And yes, this means that the error thrown at the top of the article could just as easily read “fatal: remote cheese already exists.”

Remote “origin” might’ve been configured if you cloned the repo

Since “origin” is such a common convention, there’s a good chance that any repository you clone already has a remote configured with this name, because remotes are included when a repository is cloned.‍

Cloning a repository and trying to add your own remote server to “origin” without realizing that that name is already in use is a very common way this error is caused. And again — the solution is to use `git remote set-url` instead of `git remote add`.

Conclusion

As I mentioned at the beginning of this article, we broke down the concept of remote repositories in Git and went over a few of the most common commands that you’ll need to understand in order to use them properly. For further reading, you can find formal documentation on the `git remote` command here.

Nota bene: It’s easy to just copy and paste random bits of code that you find on Google to quickly fix the error, but generally speaking it’s much more useful to understand the underlying concepts so that you don’t have to keep Googling the same commands over and over again. So, if anything is still confusing, I’d encourage you to re-read this article and dig into the documentation linked above, as well as try out the examples and everything else you find for yourself.В

I hope this helps, and good luck!

Learn from Nana, AWS Hero & CNCF Ambassador, how to enforce K8s best practices with Datree

рџЌї Techworld with Nana: How to enforce Kubernetes best practices and prevent misconfigurations from reaching production. Watch now.

Headingajsdajk jkahskjafhkasj khfsakjhf

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Источник

Introduction

Most of the content is written in GitHub Flavored Markdown with some metadata (or variables) found in YAML files. Everything is stored on a GitHub repository: https://github.com/galaxyproject/training-material.

The process of development of new content is open and transparent, using git and following the GitHub flow:

1. Create a fork
2. Clone your fork of this repository to create a local copy on your computer
3. Create a new branch in your local copy for each significant change
4. Commit the changes in that branch
5. Push that branch to your fork on GitHub
6. Submit a pull request from that branch to the original repository
7. If you receive feedback, make changes in your local clone and push them to your branch on GitHub: the pull request will update automatically
8. Pull requests will be merged by the training team members after at least one other person has reviewed the Pull request and approved it.

Agenda

In this tutorial, you will learn how to contribute to the GitHub repository:

1. Introduction
2. Create a fork of this repository on GitHub
3. Clone the GitHub repository on your computer
4. Create a new branch
5. Make your changes on this branch
6. Push your branch on your GitHub repository
7. Open a pull request
8. Make the requested changes
9. Check the automatic tests
10. Stay up to date
11. Close the Pull Request
12. Conclusion

Create a fork of this repository on GitHub

A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project:

Forking a repository is a simple two-step process:

Hands-on: Fork the repository

1. Go on the GitHub repository: https://github.com/galaxyproject/training-material

2. Click on Fork (top-right corner of the page)

   

Clone the GitHub repository on your computer

To modify the content of the repository, you need a copy of it on your computer. This step of importing a git repository is called “cloning”:

Hands-on: Clone the GitHub repository

1. Get the URL of your fork. You can find this on the main page of your fork under the green button:

   1. Click on Code (right)

      

   2. Copy the URL

      It should be something like https://github.com/< Your GitHub Username >/training-material.git

2. Open a terminal
3. Navigate with cd to the folder in which you will clone the repository

4. Clone the repository with the command:

   $ git clone https://github.com/< Your GitHub Username >/training-material.git
   

5. Navigate to the repository

Create a new branch

You have now your repository locally and you want to modify it. For this example tutorial, you will add yourself as contributor of the project to appear on the Hall of Fame.

In GitHub flow, there is a concept: one new feature or change = one branch.

When you’re working on a project, you’re going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. You should develop different features on different branches to help keep the changes you make simple and easy to review.

Here for this tutorial, you will create a branch called “my_new_branch” in which you will modify the CONTRIBUTORS.yaml file, the file used to generate the Hall of Fame.

Hands-on: Create a branch

1. List the existing branch

   The branch on which you are is shown with the *

2. Create a new branch

   $ git checkout -b my_new_branch
   Switched to a new branch 'my_new_branch'
   

3. List the existing branch to check that the branch has been created and you are now on it

This branch is added to your local copy:

Make your changes on this branch

You have created your first branch! Now you want to make the change in the CONTRIBUTING.yaml file. By changing a file in this branch, it will diverge from the main branch. It will contain data that is only on this new branch:

Hands-on: Make changes in a branch

1. Open with your favorite text editor the CONTRIBUTORS.yaml file that is on your computer

2. Add yourself in the CONTRIBUTORS.yaml file

   You should use your GitHub username and add it followed by : at the correct position given the alphabetical order

3. Save the file

4. Check the changes you made

   $ git status
   On branch my_new_branch
   Changes not staged for commit:
     (use "git add/rm <file>..." to update what will be committed)
     (use "git checkout -- <file>..." to discard changes in working directory)
   
       modified:   CONTRIBUTORS.yaml
   
   no changes added to commit (use "git add" and/or "git commit -a")
   

5. Add the file and commit the changes

   $ git add CONTRIBUTORS.yaml
   $ git commit -m "Add ..."
   

6. Check that there are no more changes to commit with git status

Push your branch on your GitHub repository

The changes you made on your branch are only on the local copy of the repository. To propagate them online, you need to push them on your fork on GitHub:

Hands-on: Push the changes

1. Push the changes to the GitHub repository

   $ git push origin my_new_branch
   

   When you git pushed, you specified origin. Git repositories can know that forks exist in multiple places. When you clone one, it creates a “remote” (a remote repository) which it names origin, set to the URL that you used when you cloned. By having multiple remotes, you can manage more complex workflows.

2. Go to your GitHub repository
3. Change to the “my_new_branch” branch:

   1. Click on Branch: main (left)

      

   2. Select the branch “my_new_branch”

4. Check that your name is in the CONTRIBUTORS.yaml file

Open a pull request

You pushed your changes to GitHub, but currently they are only on your fork. You want to have these changes in the main GitHub repository in order to appear on our Hall of Fame online. You can’t add or push directly the main GitHub repository, so you need to create what we call a pull request:

Hands-on: Create a pull request

1. Go to your GitHub repository

2. Click on Compare & pull request

   

3. Check that the selected branch are correct: main on the left and your branch name on the right

   

4. Fill in the pull request description

   

   1. Add a title for the Pull Request
   2. Add a message explaining the changes you made (Be kind )
   3. Click on Create pull request
5. Go to Pull requests to check if it is there

Once the pull is open, it will be reviewed. There are two possible outcomes:

1. Your pull request is accepted. Congratulations! Your changes will be merged into the main branch of the original repository. The website will be re-built and you will be in the Hall of Fame
2. Your pull request needs modifications: the reviewers will ask for some changes, possibly because the automatic tests are failing.

Make the requested changes

One of the reviewers of your pull request asked you to add your name after your GitHub username in the CONTRIBUTORS.yaml file

Hands-on: Make further changes

1. Make the requested changes in the CONTRIBUTORS.yaml file

   It should look like

   bebatut:
        name: Bérénice Batut
   

2. Check the changes that you made

   $ git status
   On branch my_new_branch
   Changes not staged for commit:
     (use "git add/rm <file>..." to update what will be committed)
     (use "git checkout -- <file>..." to discard changes in working directory)
   
       modified:   CONTRIBUTORS.yaml
   
   no changes added to commit (use "git add" and/or "git commit -a")
   

3. Add the file and commit the changes

   $ git add CONTRIBUTORS.yaml
   $ git commit -m "Add ..."
   

4. Check that there are no more changes to commit with git status

5. Push the new changes to GitHub

   $ git push origin my_new_branch
   

   The pull request should be automatically updated

6. Check that the new changes are added to the pull request on GitHub

Check the automatic tests

When a pull request is opened, some automated tests are automatically launched on Travis to be sure that the changes do not break the website, the URL are valid, etc.

On the bottom of your pull request, you can see the status of the tests:

• Yellow (with circle)

  

  The tests are still running

• Red (with cross)

  

  When it is red, you can investigate why by clicking on Details. You will be redirected on Travis where you can see the logs of the tests. Get in touch with us on Gitter if you need help to understand the issue.

• Green (with tick)

  

  The tests passed. Good job!

  Even it is green, we recommend to check the result of the tests, as some of tests are allowed to fail (to avoid too much noise).

Stay up to date

You now want to work on a new tutorial or make some other new changes. However since you get a local copy, some changes have happened to the original GitHub repository. You need then to update your local copy of the repository before changing anything.

Hands-on: Update the local copy

1. Move to the main branch

2. Add a reference to the original GitHub repository

   $ git remote add upstream https://github.com/galaxyproject/training-material.git
   

3. Update the local copy of the repository by “pulling” in the content of the original GitHub repository

You can now restart the GitHub flow to propose new changes: start by creating a new branch.

Close the Pull Request

Great! You now know how to make pull request on GitHub, and how to make changes after a review.
Reviewers can now approve and merge your pull request.

Because this was just a practice pull request, let’s close it again.

Hands-on: Close the Pull Request

Once you have run through all these steps, please close the pull request again.

1. Go to the list of pull request tab on GitHub
2. Click on your pull request
3. Scroll to the bottom of the page
4. Click on “Close pull request” button

Whenever you add your first real contribution, you can add yourself to the CONTRIBUTORS.yaml file in that PR.

Conclusion

With this tutorial, you have learned some basics git commands and principles:

You also learned the GitHub flow and its cycle:

1. Create a new branch in your local copy
2. Commit the changes in that branch
3. Push that branch to your fork on GitHub
4. Submit a pull request from that branch to the main repository
5. Wait for feedbacks and make requested changes
6. Update your local copy
7. Restart the cycle

You can now contribute and help us to improve our tutorials!

This tutorial was a quick introduction to explain the basics of contributing to the training material. We recommend that everyone follow a more detailed git tutorials:

• Software Carpentry tutorial which explains a bit more in detail some git commands and the concept of remote, local and stagging
• Learn Git Branching by GitHub to test the different git commands

You should also download, print and keep always with you the Git Cheat Sheet

Key points

• Work on your fork

• 1 branch = 1 feature

• 1 pull request = 1 branch

• Be careful of the branch you’re working on

• Check the automated tests

Frequently Asked Questions

Have questions about this tutorial? Check out the tutorial FAQ page or the FAQ page for the Contributing to the Galaxy Training Material topic to see if your question is listed there.
If not, please ask your question on the GTN Gitter Channel or the
Galaxy Help Forum

Feedback

Did you use this material as an instructor? Feel free to give us feedback on how it went.

Did you use this material as a learner or student? Click the form below to leave feedback.

Citing this Tutorial

1. Cyril Monjeaud, Bérénice Batut, Contributing with GitHub via command-line (Galaxy Training Materials). https://training.galaxyproject.org/training-material/topics/contributing/tutorials/github-command-line-contribution/tutorial.html Online; accessed TODAY
2. Batut et al., 2018 Community-Driven Data Analysis Training for Biology Cell Systems 10.1016/j.cels.2018.05.012

@misc{contributing-github-command-line-contribution,
author = "Cyril Monjeaud and Bérénice Batut",
title = "Contributing with GitHub via command-line (Galaxy Training Materials)",
year = "",
month = "",
day = ""
url = "url{https://training.galaxyproject.org/training-material/topics/contributing/tutorials/github-command-line-contribution/tutorial.html}",
note = "[Online; accessed TODAY]"
}
@article{Hiltemann_2023,
	doi = {10.1371/journal.pcbi.1010752},
	url = {https://doi.org/10.1371%2Fjournal.pcbi.1010752},
	year = 2023,
	month = {jan},
	publisher = {Public Library of Science ({PLoS})},
	volume = {19},
	number = {1},
	pages = {e1010752},
	author = {Saskia Hiltemann and Helena Rasche and Simon Gladman and Hans-Rudolf Hotz and Delphine Larivi{`{e}}re and Daniel Blankenberg and Pratik D. Jagtap and Thomas Wollmann and Anthony Bretaudeau and Nadia Gou{'{e}} and Timothy J. Griffin and Coline Royaux and Yvan Le Bras and Subina Mehta and Anna Syme and Frederik Coppens and Bert Droesbeke and Nicola Soranzo and Wendi Bacon and Fotis Psomopoulos and Crist{'{o}}bal Gallardo-Alba and John Davis and Melanie Christine Föll and Matthias Fahrner and Maria A. Doyle and Beatriz Serrano-Solano and Anne Claire Fouilloux and Peter van Heusden and Wolfgang Maier and Dave Clements and Florian Heyl and Björn Grüning and B{'{e}}r{'{e}}nice Batut and},
	editor = {Francis Ouellette},
	title = {Galaxy Training: A powerful framework for teaching!},
	journal = {PLoS Comput Biol} Computational Biology}
}

                   

Congratulations on successfully completing this tutorial!

Developing GTN training material

This tutorial is part of a series to develop GTN training material, feel free to also look at:

1. Creating a new tutorial
2. Contributing with GitHub via command-line
3. Overview of the Galaxy Training Material
4. Creating Slides
5. Creating content in Markdown
6. Adding Quizzes to your Tutorial
7. Principles of learning and how they apply to training and teaching
8. Design and plan session, course, materials
9. Including a new topic
10. Contributing with GitHub via its interface
11. Teaching Python
12. Creating Interactive Galaxy Tours
13. Updating diffs in admin training
14. GTN Metadata
15. Tools, Data, and Workflows for tutorials
16. Running the GTN website online using GitPod
17. Running the GTN website locally
18. Adding auto-generated video to your slides
19. Generating PDF artefacts of the website

This article discusses how to resolve the issue git fatal: remote origin already exists error during the push or add commands.

Fix git fatal: remote origin already exists error on push

You must run the ‘git init’ command to enable git for any application or folder/directory.

Once git is initialized, we must either create a new repository or clone an existing repository to map this to the existing directory.

if this directory is created in the nested folder of any git repository, the git command throws git fatal: remote origin already exists error.

What does its origin mean?

This error comes during multiple use cases.

• created a local nested folder app, It is a child folder of a local git repository, these folders map to the new remote repository.

B:blogjswork>git remote add origin https://github.com/intkiran/react-auth0-login.git
fatal: remote origin already exists.

An error would

fatal: remote origin already exists.

From the above code, It creates an origin local name and adds it to an existing repository.

In any local repository, How do you know the remote repository url?
using the -v option gives the local name with a remote url as described following

And the output is

origin  https://github.com/intkiran/react-auth0-login.git (fetch)
origin  https://github.com/intkiran/react-auth0-login.git (push)

It gives the remote repository url mapped with the local name i.e origin.

Origin is the local name for the remote repository given by default.

This error occurs after adding a new url to the existing origin.

This post covers the solution for the following errors in the git command

• fatal: No such remote:
• Remote origin already exists on ‘git push’ to a new repository

There are many ways we can fix this.

Remove the original name from the given existing repository

First, delete the local name origin for a given remote repository using the following command.

next, add the original name to the new remote repository

git remote add origin remote-repo-url

set-url Change origin name from the given existing git repository

git remote set-url neworigin remote-repo-url

if remote-repo-url does not exist, it gives an error fatal: No such remote:.

Replace current origin with new url in Git

below set the new url for the local name origin.

git remote set-url origin remote-repo-url

rename existing origin name in Git

The last approach is to rename the existing origin to the new name

git remote rename origin neworigin

Finally, Verify the name mapped to the URLs using the below command.

wrap

There are many ways we can fix these errors with the above solutions.