Remotes

Adding and removing them, choosing the active one, and the links they give you.

Remotes at the foot of the sidebar shows how many servers this repository knows about and which one is active; clicking it opens that page of Repository ▸ Repository Settings…, where the list itself is. A cloned repository has origin; an initialised one has none until you add one.

Innesta has read the host out of the URL and said so; nothing was configured to make that happen.

The list

One row per remote: its name, its URL, and a badge saying which host Innesta has recognised from the URL. A tick marks the selected remote — the one the provider integrations read from, and the one the cards under the list are about. Click a row to select it.

That selection is Innesta’s alone. It changes nothing in Git: it is not where a push goes and not what a branch tracks, both of which are Git’s own configuration and are set elsewhere.

A URL too long for the row is shortened in the middle, and pointing at the row shows the whole of it. Copy URL is in the row’s context menu, and Edit ▸ Copy (⌘C) does the same while the row has the keyboard focus.

The bin at the right-hand end of a row removes that remote, after a confirmation that names it. The same action is in the context menu of the remote’s own group in the sidebar’s branch list.

Adding one

Add Remote, under the list, opens a name and a URL side by side. When the repository has no remote at all the two fields are simply there, with nothing to open first. origin is suggested as the name while that name is free.

Return in the URL field does what the button under the fields does: both ask for a confirmation, and then add the remote. A name already in use, a name Git would not accept or a URL it would not accept is refused before that, with the reason written under the fields. The new remote is selected as soon as it exists, and the form closes behind it; a cancelled confirmation or a failed add leaves what you typed where it was. Cancel throws the draft away and closes the form; Escape closes the whole settings sheet.

From the remote’s URL, Innesta works out who is hosting it — GitHub, GitLab, Bitbucket or Azure DevOps — and can then give you a web link to:

  • the repository,
  • the branch you are on,
  • a commit,
  • the pull or merge request for the branch.

Links can be copied, or shared through the macOS Share Sheet, so sending a colleague the exact commit you are looking at is two steps rather than a hunt through a browser.

Custom domains

Detection reads the URL, so a GitHub Enterprise or self-hosted GitLab on a domain of its own is not recognised automatically. On such a remote the badge is a menu instead — Automatic, GitHub or GitLab — and what you choose is remembered for that remote.

Provider links work for all four hosts, because a link is just a URL built from the remote.

Reading pull requests and pipelines needs the host’s API, and that only works for GitHub and GitLab — see GitHub and GitLab. Bitbucket and Azure DevOps get links and nothing more: on a repository whose active remote is one of those, the sidebar’s Collaboration group is simply not there, rather than being there and empty.