Switching my code from gitweb to Gogs

gogs-logoSince 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.


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:

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:

Doing so starts Gogs’s built-in SSH server on a separate port (line 4) and with a separate authorized_keys file (line 5). 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.


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.

There are 4 comments Go To Comment

  1. Pingback: Björn Schießle (bes)’s status on Monday, 14-Mar-2016 23:36:07 UTC – GNU Social /

  2. Konstantin /

    Hallo Max,

    ich habe mir auch Gogs auf meinen Uberspace installiert. Ich finde die Anwendung richtig toll und würde sie in Zukunft gerne wirklich nutzen. Leider bin ich aber bisher an der Einrichtung von SSH gescheitert. Da Gogs immer beim Entragen eines SSH-Keys die authorized_keys von Uberspace überschreibt, ist das für mich eigentlich keine Option. Deswegen versuche ich den built-in SSH-Server zum Laufen zu bekommen. Leider bisher ohne Erfolg.

    Ich habe zunächst überprüft, ob der Port 61777 frei ist (Uberspace weist im Wiki darauf hin, dass nur Ports zwischen 61000 und 65535 zu benutzen sind!).

    netstat -tulpen | grep 61777

    Dann habe ich in /home/xxxxx/gogs/custom/conf/app.ini das eingetragen:

    SSH_PORT = 61777
    SSH_ROOT_PATH = /home/xxxxx/.ssh/gogs

    Anschließend habe ich Gogs neu gestartet:

    svc -d ~/service/gogs
    svc -u ~/service/gogs

    In /home/xxxxx/gogs/log/gogs.log kann man sehen, dass Gogs korrekt startet:

    2016/09/11 13:xx:xx [I] SSH server started on :61777
    2016/09/11 13:xx:xx [I] Listen:

    Dann habe ich auf mienem Rechner einen neuen Schlüssel my_git_key.pub für Git/Gogs generiert und den Inhalt im Admin-Bereich von Gogs eingetragen. Dabei wird auch nicht mehr die authorized_keys mit dem Uberspace-Schlüssel überschrieben. Soweit, so gut.

    Wenn ich nun aber mit Git eines der Repositories klonen möchte, bekomme ich eine Fehlermeldung:

    git clone ssh://xxxxx@git.domain.tld:61777/user/testprojekt.git

    Cloning into ‚testprojekt’…
    ssh: connect to host git.domain.tld port 61777: No route to host
    fatal: Could not read from remote repository.

    Ich habe leider keine Idee, woran das liegen könnte. Habe ich was falsch gemacht, was übersehen oder nicht verstanden?

    Vielen Dank und beste Grüße!

  3. Konstantin /

    So, habe das Problem entdeckt. Der von mir eingetragene Port 61777 war nicht offen. Man muss sich in Uberspace einen Port öffnen (https://wiki.uberspace.de/system:ports#firewall) und diesen dann in Gogs app.ini als SSH_PORT eintragen. Dann Gogs neu starten und alles läuft, wie es soll!

    1. Max / Post Author

      Ah ja gut, wollte gerade eine Antwort mit demselben Hinweis schreiben. Dann ist ja alles gut, viel Spaß damit! :)

Leave a Reply