Switching my code from gitweb to Gogs

Since end of 2014 I published some of my Free Software code – mostly Bash, R and HTML/PHP – on a self-hosted gitweb instance. I did this because I wanted to share the work I’ve done with other people because I’ve learnt a lot by reading other people’s code. Although I’m just a „hobby programmer“, I hoped at least some people can benefit from it.

The last few days, I switched from gitweb, a very simple web interface for my git repositories, to Gogs, a feature-rich webservice which still is lightweight, and quite simple to install and maintain – and of course Free Software! By doing so, people can now register with my Gogs instance, open issue tickets, fork my projects and send pull requests – very similar to non/semi-free services like GitHub or GitLab.

Installation

As a user of the German hosting service Uberspace I had to follow some special ways to install Gogs. But thanks to a nice guide it was quite simple, so it was finished after only 15 minutes. The only tricky part was the SSH feature with which I spent a few hours to make it work. The problem was that using the same public key with Gogs as you’re using for logging into the server’s SSH won’t work. You’ll have to generate a new SSH key and use it’s public key for Gogs. Then you have to edit your client’s SSH config:

Host src.mehl.mx
  HostName src.mehl.mx
  User your-username
  IdentityFile ~/.ssh/id_rsa_gogs
  IdentitiesOnly yes

This forces your client to use the Gogs-specific SSH key for every connection to src.mehl.mx – and not the default one for this IP/server. However, this is only a problem for you as the administrator, not for other users. It took some time for me to find that out :)

Update: It’s best to use the built-in server if you cannot create a separate user for Gogs and if you depend on using the default ~/.ssh/authorized_keys file for other use cases than gogs (e.g. to log in). The problems lies in Gogs behaviour: sometimes it rewrites the authorized_keys file without being asked to do so, and as a result you cannot log into the user’s account anymore via SSH! To make the solution easy for you, here’s the excerpt of my custom/conf/app.ini file:

[server]
START_SSH_SERVER = true
SSH_PORT     = ${DEDICATED_SSH_PORT_FOR_GOGS}
SSH_ROOT_PATH = /path/to/the/separate/authorized_keys/file

Doing so starts Gogs’s built-in SSH server on a separate port (line 3) and with a separate authorized_keys file (line 4). Of course, you’d have to open this TCP port in your firewall. Downside: The SSH links for cloning the repository don’t look that tidy if it’s another port than 22.

Migration

Before beginning with switching to Gogs, the migration process was the most intimidating part of the whole story for me. In the end, it was really simple! In the Gogs web panel you can choose if you want to create an empty new repository, or a „new migration“. Choosing the latter enables you to name the old git repository’s link, a new name and a description. It then copies the current status and all past commits to the new repository! I didn’t test it with branches, and migrating issues might be a burden too (see update below). But hey, for me as a light user it was just perfect :)

Feel free

Now please feel free to browse through my repositories and work with them. You can also have a look at my archived, not-working-anymore gitweb page to see the striking differences between both.

Update 28.02.2016:

I tested the migration assistant with a larger repository. It still worked like a charm: All branches, releases and commits are taken over. However, issues, pull requests, and wiki entries are not transferred, at least not natively. Maybe there’re tools for that?

Additionally, I more deeply elaborated the SSH problems and solutions if you’re using a shared host, or/and if you cannot create a separate user for Gogs and you use SSH keys to login into that user.



Comments