6

Due to my old installation of Gitlab being too difficult to upgrade (Thread on TKL support forums: http://www.turnkeylinux.org/forum/support/20120913/upgrading-gitlab ), I have downloaded the current TKL Gitlab distro, and followed Gitlabs standard upgrade path so that I now have a fully upgraded Gitlab 6.1 installation running with TKLBAM and all that good stuff. So far so good.

But, it turns out that our old version of gitlab does not give HTTP urls to repos, so that means that I can't use the "Import existing repository" function in Gitlab 6.1

I know that i can simply copy the old Git repositories from the old VM to the new one, but how can I make these repositories visible in Gitlab on the new VM?

5 Answers 5

13

I recently migrated from gitolite to gitlab and the official rake task gitlab:import:repos worked for me. I am using gitlab 6.1.0 (82f3446). Here is what I did:

  • rsync bare repos from gitolite to repositories/{group}/. Make sure to replace {repository} with the name of the gitolite repo, and change the hostname of your gitlab server.

    rsync -rth --progress repositories/{repository}.git \
    git@gitlab-server:/home/git/repositories/{group}/
    

    Here, {group} is the name of the user group you want the repository to be added to. If you don't have any specific group, choose root as the group name.

  • Fix permissions – only necessary when the rsync user is not git:

    sudo chown -R git:git repositories/{group}/
    
  • cd ~/gitlab

  • Run the rake task to import all new repositories:

    bundle exec rake gitlab:import:repos RAILS_ENV=production
    

Now if you login as Administrator you will find the new project added.

For more information, refer to the "Import bare repositories into GitLab project instance" under http://{your-gitlab-server}/help/raketasks.

In your case, you can login to your old TKL system and rsync all bare repos to the new instance, followed by an import.

3
  • When running that rake task, I get the error: Could not locate Gemfile. What could the issue be? I'm running GitLab 5.0.1
    – Batandwa
    Commented Jan 19, 2014 at 8:52
  • @Batandwa Are you sure you're in the directory /home/git/gitlab?
    – slhck
    Commented Jan 20, 2014 at 12:21
  • 2
    This fails for me with a fresh install of v6.5.1 on CentOS 6.5... I copy a bare repo to /home/git/repositories/username/repo.git, but the rake tells me "Failed trying to create group username". It then creates an empty repo in /home/git/repositories/root (Administrator's namespace). See github.com/gitlabhq/gitlabhq/issues/3693 and github.com/gitlabhq/gitlabhq/issues/4137
    – big_gie
    Commented Jan 23, 2014 at 20:43
7

One option would be to:

  1. Clone the old repo from gitlab onto a dev machine.
  2. Create a blank repo on the new gitlab.
  3. Add the new repo as a remote on the dev machine.
  4. Push everything back to the new repo.
  5. Remove the old repo from remote repos list.

To create a remote called newRepo, do: git remote add newRepo gitlab.localhost.com:User/newRepo.git (replace the url on the end with the one for your repo)

3
  • Will clone give me all branches? Commented Oct 1, 2013 at 7:57
  • 1
    Yes it should. You can check which branches you have after the clone by running git branch -a. If it has missed any, running git fetch --all should retrieve them.
    – ChrisA
    Commented Oct 1, 2013 at 8:02
  • 2
    Ok, this is nifty if you have one repo. But what if you have 50+ repo's, grouped, with 30+ users, with different access rights based on groups/repos? Are you then up THAT creek without a paddle?
    – demaniak
    Commented May 6, 2016 at 6:53
5

I did it practically the following way after reading ChrisA answer, which gave me a little headache about how to do it practically. The example copies a repo from github to gitlab, to make source and destination a little bit clearer.

  1. Clone the old repo from github onto a dev machine (which creates a bare repo):

    $ git clone --mirror [email protected]:me/myrepo.git
    
  2. Create a blank repo on the new gitlab.

  3. Add the new repo as a remote on the dev machine.

    $ cd myrepo.git
    $ git remote add newRepo [email protected]:me/myrepo.git
    
  4. Push everything back to the new repo.

    $ git push --mirror newRepo
    

That's it.

This way it copied all branches and tags to the new destination.

You can now remove the cloned bare repo from your dev machine.

1
  • I find this makes it far easier, albeit lengthy, to migrate repositories from GitLab 6.0 to 6.9.2.
    – signus
    Commented Jun 17, 2014 at 17:35
0

If your Gitlab is >= 8.9, then you can use export/import to migrate repos.

0

Since GitLab 13.8 (January 2021), you now have:

Migrate Groups directly between instances

A faster and easier way to migrate your GitLab Groups is on the way.
Group Migration is a new feature that lets you copy a GitLab Group from one instance to another directly, without having to export and import any files.

In this release, we migrate only the Group object with basic fields.
We plan to follow up with more and more fields and related objects until all relevant data in a Group is migrated in this easy-to-use fashion.

See Documentation and Epic.

Not the answer you're looking for? Browse other questions tagged or ask your own question.