TicGit Issue Tracker

TicGit-ng is an issue tracker and – as the name suggests – tightly coupled within a Git repository. Thus, the idea is to keep the issue tracking system along with the source rather than setting up a web server instance with one of the many open systems or paying for an equivalent service.

Since Lucid, TicGit is packaged for Ubuntu, so you can simply grab the CLI tool and a simple web server with

sudo apt-get install ticgit ticgitweb

Alternatively, you can also install the gem tool and pull everything from the Rubygems site

sudo apt-get install ruby rubygems
sudo gem install git sinatra haml sass

Before adding tickets, you have to run ti init in a directory that contains a Git repository. ti new fires up $EDITOR, to let you enter a ticket summary and additional tags. You can also take a short cut and enter a new ticket with ti new -t 'summary'. ti list lists all open tickets.

Now, if you want to use one of the more advanced commands such as comment, state etc., you have to checkout a ticket by its TicId or its position on the list. To me this is a little bit awkward but okay. Although you could simply push and pull the TicGit branch to your remote, it is probably a better idea to use the builtin sync command.

Because it is quite cumbersome to remember and type all these commands, Nick Anderson wrote a Bash completion script that completes the options. I enhanced the script with ticket completion and some more commands that made it into TicGit since 2008. To enable Bash completion, put the script into /etc/bash_completion.d/.

To start the TicGit web server, simply change into a TicGit-enabled repository and run ticgitweb. Point your browser to 0.0.0.0:4567 and you’ll be greeted with a simple interface to TicGit:

Ticket details
Details of a ticket.

However, as far as I can see there are also some drawbacks to the TicGit approach:

  • Although – being based on Git – it allows for a very nice distributed issue tracking system, I cannot imagine it to be used by a larger community as it simply does not scale: Everyone would have to pull from everyone to have a consistent view of all issues.
  • In the same vain, TicGit is probably a little less appealing to people not friends with the command line.
  • Performance is somewhat lacking. Most commands are executed after a noticeable latency. This may or may not be caused by Ruby. Who knows?
  • Extensibility is non-existent. For example, there are four pre-defined ticket states (open, hold, invalid, resolved) but you cannot change them nor add new ones. Also mandatory features found in larger tracking systems such as versions and milestones are missing.

Despite these points, , TicGit is a perfect solution to keep track of bugs and issues for smaller projects such as my blog here.


Discussion