Migrating from Trac to GitHub

Vincent Bernat

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

Trac & spam#

How to fight spam with Trac#

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

One of them is Akismet, a web service who can tell you if some message is a spam or not. It is able to 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 is 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 setup a public account and adding somewhere in 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 catched them in my RSS flow or in 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,
  • 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 which uses 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 the 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 which is synchronised 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 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 commits, tickets, projects and subscribe to a lot of events. You can receive and answers tickets by mail.

However, an accound 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 is less 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 into 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 exists 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.

Share this article