When and why?
We wrote yesterday about the GitEnt-Scm.com shutdown due on April 30th, 2016. Now the issue you would be facing is: how to migrate somewhere else?
Although StackOverflow already contains over 800 response threads when asking this question we thought that giving a practical example based on a real-life GitEnt repository would allow you to avoid the trial & error discovery.
Step 1 – Mirror clone
When you want to clone a repository for the purpose of migration, you really want everything, including all the other refs that are not branches:
- Git Tags (refs/tags/*)
- Git Notes (refs/notes/*)
- Gerrit Reviews (refs/changes/*)
- Gerrit Configs (refs/meta/*)
Instead of using a standard clone, you can do a “git clone –mirror”, which implies –bare and thus does not generate a working copy.
$ git clone --mirror ssh://email@example.com/git/myorg/myrepo.git Cloning into bare repository 'myrepo.git'... remote: Counting objects: 109, done remote: Finding sources: 100% (109/109) remote: Total 109 (delta 19), reused 83 (delta 19) Receiving objects: 100% (109/109), 66.42 KiB | 0 bytes/s, done. Resolving deltas: 100% (19/19), done. Checking connectivity... done.
Step 2 – Create empty repo on the new Git Server
You need to have an empty target repository where to push your mirrored local clone. Note that most of the Git Servers propose you to create a first master branch with a README, but, in this case, you do not need it and it would only create more trouble in your migration path.
Example for GitHub:
– Go to https://github.com/new and create the ‘myrepo’ repository
– Do not tick any of the suggested README or LICENSE auto-generation
– Once the project is created, GitHub provides you with the repository Git URL (e.g. firstname.lastname@example.org/myrepo.git)
Step 3 – Push to the new Git Server
You are now ready to push to the target repository, and we can use the useful option “–mirror” again.
Similarly to the clone, “–mirror” automatically include all refs, including the non-branch ones (tags, notes, reviews, configs, …); it provides the behaviour of removing all the refs that are not present in your local clone. You should never use this option when you have a “regular default clone” as you would risk removing all the remote refs that have not been typically cloned with a standard default “git clone” operation.
Example for GitHub:
$ git push --mirror email@example.com/myrepo.git Counting objects: 109, done. Delta compression using up to 4 threads. Compressing objects: 100% (61/61), done. Writing objects: 100% (109/109), 66.42 KiB | 0 bytes/s, done. Total 109 (delta 19), reused 109 (delta 19) To firstname.lastname@example.org/myrepo.git * [new branch] refs/changes/02/802/1 -> refs/changes/02/802/1 * [new branch] refs/changes/03/803/1 -> refs/changes/03/803/1 * [new branch] master -> master * [new branch] refs/meta/config -> refs/meta/config
Step 4 – Import into GerritHub.io (Optional)
Your repository has not been fully migrated to your new target server. If you wish now to keep on using Gerrit Code Review for your Development Workflow, you can link your repository to Gerrit using GerritHub.io
The YouTube Video explains how to perform this last operation using GerritHub.io import Wizard.
Need more help?
Do you require more help? Contact our Sales Departement at email@example.com and we will provide the extra support you need or perform the migration for you to GerritHub.io.