How-To's Sendtoall

Mirroring an External Git Repository in Space

Creating a new Git repository in Space is easy. You can create and initialize a new or empty repository and start pushing code, or migrate an existing Git repository from GitHub or BitBucket and make it available in Space, including all branches, tags and commits.

There’s an additional option: mirroring a repository. In this post, let’s have a closer look and see how you can mirror Git repositories in Space.

Why mirror a Git repository?

A mirrored Git repository in Space is an always-in-sync copy of another Git repository. Synchronization can be “pull-only”, when Space automatically pulls all commits (and tags & branches) from a remote. A bi-directional mirror can be set up as well, where changes pushed to Space are automatically pushed to the remote.

Mirror repository from external Git
When an “always-in-sync” mirror of a public repository is needed, Space can help. Having such a mirror may reduce latency while accessing the main repository. Git repository mirrors can be browsed and searched in Space, even if the original repository does not provide that functionality.
Repository mirroring can also help simplify user management. Teams can work with the repository that is hosted in Space, where authentication and access are handled. Space itself then propagates commits and other changes to the remote repository.
A mirrored repository can also help with migrating to Space. Instead of doing a big-bang migration where all developers have to update their Git remote immediately, they can push changes to both the original repository and Space. Both repositories will always be in sync, so there’s no rush to move developers and continuous integration servers over to a new repository URL at once.
At JetBrains, we have a few repositories (such as Kotlin) that we host in Space, and mirror on GitHub. Our developers typically commit code to Space, and external contributors use GitHub. Space keeps both repositories in sync.

Setting up a Git repository mirror

In any project, we can create a new Git repository. Mirroring is one of the options available when setting up the repository:
Setting up repository in Space to mirror a project from GitHub
After selecting Mirror a repository from another Git hosting, we’ll have to specify the remote URL and set up the behavior of our mirror:

  • Since we are mirroring, we want to check the remote repository for changes and bring them to Space. This can be done periodically and/or when a developer does a git fetch.
  • To propagate pushes from Space to the remote repository, enable Allow push to proxy.

Optionally, we can set a Git refs pattern (refspec) to filter out the branches we want to mirror. For example, we can set the refspec to +refs/heads/master to only mirror the master branch.
We’ll also have to set credentials to connect to the remote repository. If the remote is public, fetching can be done anonymously. For private repositories, as well as repositories we want to push to, we will need to set credentials – either a username/password combination or an SSH key.
After creating the mirrored repository in Space, an initial synchronization will happen to make sure all commits and branches (matching the refspec) are available in Space.

What’s next?

Once set up, we can start working with our mirrored repository. We can pull changes from Space, commit code to our repository, and explore and review code. Developers committing to Space will see their changes in the remote, and those committing to the remote directly will see those changes in Space.
Give JetBrains Space EAP a try and let us know what you think!

Comments below can no longer be edited.

6 Responses to Mirroring an External Git Repository in Space

  1. Avatar

    Mark Wrenn says:

    February 6, 2020

    Space represents a very interesting integrated environment. I like the ideas that have been implemented. My struggle is “Why change?”. We have already invested in using Bitbucket as our repository. We use MS Teams for internal chat. We use Google Calendar for calendaring. To switch to Space would require a great deal of internal ‘selling’ and an investment of time and money to switch technologies. I don’t see the compelling reason to do so.

    • Avatar

      Maarten Balliauw says:

      February 7, 2020

      Hi Mark,

      The key ingredient here is “integrated”. As you mentioned, Space integrates multiple services into one service and one story. Less context/app switching, uniform UI and UX, transparency and availability of information (e.g. absences shown when hovering a code reviewer’s profile name), and more effective collaboration are just some of the benefits this may bring.

      Features like git mirroring can help ease migration. For example, a small team can start working with Space, mirroring a repo on one of the other services you mentioned without having to bother the rest of the organization yet. So starting small is definitely possible.

  2. Avatar

    Elad says:

    February 17, 2020

    Hi! I’m curious what would the git history looks like in the bi-directional sync mode? Say when changes are pushed from Spaces to a Github repo, who’s the author of those commits on Github? Is it the original author, or is there a “Spaces machine user” that acts as the author?

    And if could share a bit about how this sync works technically?


    • Avatar

      Maarten Balliauw says:

      February 19, 2020

      Hi Elad,

      The git history would look… the same 🙂 Git allows specifying the commit author (see docs) which can be different from the user performing a push to the remote. (Space has an option to enforce these being the same, but for Git itself this is not a requirement)

      So in essence, the commit author != the authenticated user pushing to a repository. When performing a sync, the author of each commit is synchronized as-is, without the need for a machine user/sync user.

      On the technical side we have our own implementation, but in essence something similar can be done by using git hooks that perform the same command against a remote repo. E.g. when pushing, have a hook that also pushes to another remote.

  3. Avatar

    Edi says:

    March 12, 2020


    we invested much time and money to migrate from less integrated CI / CD landscape to Azure Devops. Should we consider Jetbrains Space?

    • Valerie Andrianova

      Valerie Andrianova says:

      March 13, 2020

      Jello Edi,
      Sure, we do recommend you considering Space when Automation (CI/CD) is available.