Migrating from Trac to GitHub

Vincent Bernat

I was hosting my projects on several Trac instances on a dedicated server. However, for several months, spam was pouring.

Trac & spam#

How to fight spam with Trac#

There is no built-in mechanism in Trac to fight spam. However, plugins enable to set up several ways to stop spam (or at least, reduce it).

One of them is Akismet, a web service that can tell you if some message is spam or not. It can catch most of the spam. A bayesian filter complement this service. A learning step is mandatory and can become cumbersome when the vast majority of the tickets you receive are just spam. I used these two mechanisms on my Trac instances.

Another path is to require an account to post a ticket. Creating an account each time you want to create a ticket for some software is burdensome. I did not want to do this to the poor souls that have found a bug in one of my projects. An alternative is to set up a public account and adding somewhere on the page some instructions on how to use it when you want to open a ticket but don’t want to open an account.

Removing spam#

Despite Akismet and the bayesian filter, I still got two or three spams a day. I caught them in my RSS flow or my email if they were not classified as spam.

There are two steps to remove the spam:

  • tell the bayesian filter by using the administration panel in the web interface; and
  • remove the spam from the database using some SQLite commands directly on the server hosting the Trac instance.

Indeed, Trac does not propose the possibility to remove a ticket. Of course, there are plugins, but you must find them, install them, find how to configure them, etc.



GitHub is a popular source code hosting service using Git as a backend. This is a proprietary platform but a lot of open source projects have migrated to it, thanks to its features and good performance.

Everybody is on GitHub. This was the ideal opportunity.

Update (2011-05)

Peter Pentchev did point me to Gitorious which is a free alternative to GitHub. Its source code is licensed under the AGPL. Unfortunately, I did not consider it because it was lacking an issue tracker.


First, GitHub allows you to host Git repository. You push your Git repositories. There is a nice and fast web interface to browse them. However, I still keep an instance of cgit.

Then, GitHub is very popular because they drive people to fork projects. With one single click, you can fork your favorite project. You get a copy that is synchronized with the forked project.

There is also a wiki (accepting many markup syntaxes). This wiki is also available through Git.

At last, GitHub offers a minimalistic ticket system. You open a ticket, you make some comments, you can add a tag or two and you can close it. That’s all. Quite light. But enough for small projects like mine.

However, there is more! Do not open a ticket to send a patch. There is no way to attach files to tickets. You need to fork the project, create a branch with your patch and request a “pull” for your branch. This will appear as a ticket but your commits will be linked to it. The author can then review and comment on your branch, ask for some changes and if they want to integrate it, a simple merge is sufficient. They can even do it using the web interface. Convenient.

Socially, you can comment on commits, tickets, projects and subscribe to a lot of events. You can receive and answers tickets by mail.

However, an account is mandatory to open a ticket. Since there is a lot of projects on GitHub, this account should be useful for a lot of software.

To cut a long story short, even if GitHub is a proprietary platform, it offers nice and interesting features. More and more projects migrate from Google Code to GitHub even if there are fewer features on the latter.


I have searched for tools to migrate automatically tickets from Trac to GitHub. For example, there is SD.

Update (2011-05)

Olivier Berger is involved in ForgePlucker, a project aimed to provide tools to import and export data for various forges.

At last, I have done it manually. GitHub API is well documented and there exist bindings in various languages including Python but it is a very limited API. You can’t choose the number of the ticket nor its date.

I have also rewritten README files to use the markdown markup and avoid the use of wiki pages when possible.

I have also put some URL redirections with the help of nginx.

In conclusion, even if maintaining Trac instances was not a lot of work, one thing that I do not have to do anymore. And no spam on GitHub, I assume.