Classic Migration

Most moves involving Git repos are likely to differ significantly from my special case. You will usually need to move from SERVER_1 to SERVER_2. You can see the specific steps in Listing 1.

git clone <ORIGIN-URL> <LOCAL_REPO>
cd >LOCAL_REPO>
git branch -a
for current_branch in $(git branch -a | grep -o -E '(remote.*)' | grep -v ' -> ' | cut -f3 -d'/') ; do
  git checkout "${current_branch}";
  git pull;
done
git fetch --tags
git remote rm origin
git remote add origin <NEW_ORIGIN_URL>
git push origin --all
git push --tags

The first line clones the repository from the previous server to <LOCAL_REPO> and is followed by a change to the directory of the new <LOCAL_REPO> working copy. The git branch -a lists all branches and checks them out. The fetch ensures that all the tags in the repository exist in the working copy.

With the tags, all the data from the remote repository are now on the local system. The command

git remote rm origin

cuts the connection to the previous server to receive the URL of the new server as the origin in the next git remote line. Finally, the content and tags are pushed to their new home in the last two lines.

Conclusions

With very little risk and manageable overhead, you can get rid of potentially outmoded software within a few hours. Although Gogs might live on and regain momentum again at some point, I don't want to rely on that possibility. I consider it important not to leave something as fundamental as version control to chance. During this move, I realized once again how sophisticated and powerful Git really is. It almost seems as if Linus Torvalds anticipated all the use cases during development.