not2qubit
not2qubit

Reputation: 16920

What is the difference between "git remote add origin", " set-url origin" and config...?

There seem to be at least 3 ways to do what sounds as the same thing.

# 1. git remote add origin https://[email protected]/x/y.git
# 2. git remote set-url origin ssh://[email protected]/x/y.git 
# 3. git config --local remote.origin.url ssh://[email protected]/x/y.git

Note: This may seem as a duplicate of THIS but those answers are incomplete and do not explain the difference of changing the URL vs the "remote"?

EDIT:

Doing some further googling: From this SO answer:

A remote in git is basically a bookmark for a different repository from which you may wish to pull or push code. The bookmarked repository may be on your local computer in a different folder, on remote server, or it may even be the repository itself... but the simplest analogy is a bookmark. The repository doesn't even have to be a version of your repository, it may even be a completely unrelated repository.

and this:

origin is not the remote repository name. It is rather a local alias set as a key for the remote repository URL.

Upvotes: 4

Views: 7018

Answers (3)

Khem Raj Regmi
Khem Raj Regmi

Reputation: 2270

Not so Different but they are different

Actually When you run git remote add origin [email protected]:User/TestRepo.git, then a new remote created named origin.

When you run git remote set-url origin [email protected]:User/TestRepo.git,git searches for existing remote having the same name origin and change it's remote repository url, but if git unable to find any remote having name origin, It will raise an error fatal: No such remote 'origin'.

Upvotes: 1

torek
torek

Reputation: 488183

The git remote command is meant for manipulating (working with, adding, and removing) remotes. It has ten (!) sub-commands:

  1. git remote add
  2. git remote rename
  3. git remote remove
  4. git remote set-branches
  5. git remote set-head
  6. git remote get-url
  7. git remote set-url
  8. git remote show
  9. git remote prune
  10. git remote update

Each sub-command may have its own sub-sub-commands or options; and if run with no sub-commands at all, git remote simply lists all remotes.

For whatever reason, you are asking about only two of the ten sub-commands: add and set-url. This may be because you are not sure what a remote is in the first place. The short answer is that a remote is just a name, but it's a name that is used to keep track of another Git repository, at some other URL.

While origin is a pretty standard remote name, it's not the only possible remote name—and your own repository may have no remote, in which case origin is not the name of one of your remotes, since you have none.

Still, many if not most repositories have exactly one remote, because so many are created by git clone. The git clone command automatically creates one remote, which it names origin unless you tell it to use some other name. So most repositories already have a name origin.

git remote add

What git remote add is for is to add a new remote. If you have one remote now, and you add another, you will then have two remotes. If you have none, and add one, you will have one.

Again, the point of a remote is to name another Git repository, and that other Git repository is going to be found at some URL. Hence, to make a remote useful, it needs a URL. So git remote add takes two arguments: the name of the new remote to add, and the URL to associate with that name.

(This omits a lot of the fancier special things you can do with remotes. I've never found some of them useful myself, but they are the reason that there are a bunch of option flags to git remote add.)

git remote set-url

What git remote set-url is for is, mainly, to change the URL associated with some existing remote. Hence it takes the name of an existing remote, and a new URL. The default action is to remove the old URL and insert the new one instead.

Git tries not to limit you to a single URL here: it allows more than one URL to be attached to each named remote. Precisely what happens when there are multiple URLs for any one remote is a bit tricky; it's best not to do this until you are comfortable with single-URL remotes.

git config

The git config command is a much lower level thing. Most of the settings you can make or change in Git are ultimately done through configuration entries, and this includes adding or deleting remotes and changing the URLs associated with any one particular remote. What this means is that the higher level git remote command often translates into one or more low-level git config operations. If you know precisely which configuration entries control which remote(s) in which ways, you can use git config to achieve some of the same things that git remote does.

Some of the things git remote can do are not merely configuration settings, so not everything is translatable like this. But adding or deleting a remote, and changing its URLs, are, and therefore can be.

Adding a new remote essentially consists of running two git config commands. If the name of the remote is R, the two configuration items are remote.R.url and remote.R.fetch. Setting the first without setting the second is not a great idea in general, and you need to know what to set the second to, so it's safer to use git remote to add a new remote.

Changing the (single) URL for an existing remote consists of running just one git config command. For remote R, that's git config remote.R.url new-url (--local is the default for git config so you may omit it). The URL does not affect the fetch value, so it is safe (albeit a bit pointless) to use git config to do this instead of using git remote to do it. If there is more than one URL attached to some particular remote name, though, git remote adds safety checks that git config totally bypasses.

Upvotes: 10

K. Khanda
K. Khanda

Reputation: 630

In first case, when you run remote origin [email protected]/User/repo, you create a new remote, which name is origin

In two other cases git is searching for an existing remote, which names are origin There is no preferred way for these examples, because commands make different things.

Upvotes: 0

Related Questions