Category: api-client

Change the URL of a Git repository

What you have to do:

  1. On Github/Gitlab, change the url of (remote) repository via the UI.
  2. On your local repo, use git remote set-url origin <new-url> to replicate the changes and thus restore the bridge between the remote and local repo.
  3. Confirm the changes are now reflected, using git remote -v.

Example

You created a Gitlab repo called client-snapchat-api but you made a mistake. The name should be snapchat-api-client instead. Additional complexity: you have cloned the project on your local environment already.

Note: the name convention related to API clients is quite standard in the industry; the -client part always suffixing (and not prefixing) the client’s name i.e. name-of-the-api-client and not client-name-of-the-api.

First step is to perform the modifications on the remote repository; via Gitlab’s settings on the User Interface, you edit to your likings:

  1. The project’s name
  2. The project’s path via the Settings Advanced section.

Notes:

  • It is common for the repo’s URL to respect the kebab-case formatting. See also Why using snake_case to spotlight the differences.
  • It is common for the project’s name and the repo’s URL to be the same.

Second step (since you have already cloned the project on local) is to reflect those new remote settings in your local repository.

This because your local project still uses the old URLs as “origin” (i.e. the source) to track down, fetch (pull) and push the incoming and out-coming changes.

In other terms, your local repo is still linked to the old remote URLs. But those URLs are no longer attached to an existing remote Gitlab project since you have just changed them (depreciated):

> git remote -v
origin git@gitlab.com:obenard/old-project-in-kebab-case.git (fetch)
origin git@gitlab.com:obenard/old-project-in-kebab-case.git (push)

Notes:

  • The -v option is short for --verbose
  • The URLs for fetching and pushing (i.e. where you get the changes from and where you push the changes at) can be different.

The following image may help you: it’s like uprooting a tree and plotting it somewhere else. The leaves being the local repos instantiated by your developers and the root the remote repository (aka the unique source of truth). You need to rejuvenate the thing by reconnecting the leaves to the torso.

In our example, our local repo is pointing at the now depreciated URLs:

> git remote -v
origin git@gitlab.com:obenard/client-snapchat-api.git (fetch)
origin git@gitlab.com:obenard/client-snapchat-api.git (push)

To edit the URLs:

git remote set-url origin git@gitlab.com:obenard/snapchat-api-client.git

To see the result:

> git remote -v
origin git@gitlab.com:obenard/snapchat-api-client.git (fetch)
origin git@gitlab.com:obenard/snapchat-api-client.git (push)

Congratulations, your local project is now again linked with a valid remote Gitlab repository and can send or retrieve information from it.

Run the extra mile: URI, URL and URN

Before getting any further in polishing our 360° overview and have a full grasp over the concept, we need to understand the difference between URIs, URLs and URNs:

  • An URI – Uniform Resource Identifier – is an identifier, like the id primary key in a table or the social security number for a person. It is used to uniquely discriminate a resource e.g. a Gitlab repository (two Gitlab repositories cannot have the name URI since you won’t know which one you are referring to otherwise).

  • An URL – Uniform Resource Locator – is an URI but with the additional specificity of also being a locator. An URL allows you to locate and access a resource on the Internet e.g. a web page like https://olivierbenard.fr/how-to-create-git-aliases/. This page is unique across the Internet: you can not find the same URL anywhere else, and also, the URL is associated with a page you can navigate through.

  • Every URLs are URIs but there are URIs which are not URLs. For instance, URN – Uniform Resource Name – uniquely identifies a resource by a name in a particular namespace. It is a nice way to talk about a resource but without implying anything about its location or how to access it. URNs are intended to be unique across time and space e.g. the ISBN – International Standard Book Number – is a unique worldwide book identifier.

Note: speaking about ISBNs, you may find book recommendations to get started as Data Engineer in the related article What is a Data Engineer.

Now that the semantic is set, you will notice that I have lied to you 😱

I have indeed implied that we will have to change the URLs of a Git repository. This was an incorrect statement.

What we have done instead with the git remote set-url origin <new-uri> command was to change the URIs, not the URLs:

> git remote -v
origin  git@github.com:olivierbenard/olivierbenard.git (fetch)
origin  git@github.com:olivierbenard/olivierbenard.git (push)

This makes sense: if you have a closer look, you will notice that the git@github.com:olivierbenard/olivierbenard.git thingy does not lead anywhere. For good reason: it is a pure URI!

And for sure, the repo is located by the following https://github.com/olivierbenard URL.

Notes:

  • To be even more specific, the command is changing the URIs and then, Gitlab takes over, changing the URLs in the background.

  • The same result as with git remote set-url origin <new-uri> can be obtained directly by editing the ~/local-git-repo/.git/config file:

    [remote "origin"]
    url = git@github.com:olivierbenard/olivierbenard.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

And you, what’s your excuse for not having a green thumb? 🌱