Bug databases and git

I've been using ticgit-ng for my TV Guide project for a few weeks now.  It is a simple ticketing system that runs directly in your git repository on a hidden ticgit branch.  Very nice.  No need to set up a separate bug database - just type ti list or ti new and you're off and racing.  There is a web interface as well, but I didn't bother with that.

The tickets are stored as flat directories and files within the repository.  Updates are normal git commits just like any other, and can be pushed up to your central repository.  A simple git pull followed by ti sync is sufficient to sync the ticket history with that pushed by someone else.  Here's the history and an example ticket for the TV Guide:

• https://github.com/rweather/tvguide/commits/ticgit
• https://github.com/rweather/tvguide/tree/ticgit/1310191258_channel-icons_931

And here are my current open tickets, from ti list:

   TicId  Title                    State Date  Assgn    Tags
---------------------------------------------------------------

   daae6d Global search            open  07/09 rhys.we…

   1bc66e Export/import bookmarks  open  07/09 rhys.we…
   33bb19 Programme view widget    open  07/11 rhys.we…
   e37deb Underrun/overrun report… open  07/20 rhys.we…
   af4bbe Partial matching on a p… open  08/14 rhys.we…
   9e8ad6 Inverse bookmarks        open  08/19 rhys.we…
   0a96ec Category matching in bo… open  08/21 rhys.we…
   8a1e8f Android application      open  08/28 rhys.we…
   d04472 Improved 7 day view      open  09/02 rhys.we…
   b4d129 Sorting in bookmark list open  09/03 rhys.we…
   921e49 Partial match is hard t… open  09/05 rhys.we…

Now, ticgit is a little simple compared to "enterprise-quality" bug tracking systems.  There are only 4 ticket states: hold, invalid, open, and resolved.  And the users need write access to the git repo or the web interface.  So ticgit may only be useful for 3-4 person projects.  But that shouldn't stop someone making a larger system using the same concepts (ticgit is written in Ruby).

The main thing I like about using git for bug tracking is that it could solve an annoying problem with continuous integration (CI) systems.  At my previous job, our features and bug fixes were done in "staging repos", which the CI system would automatically integrate, build, and test.  Any compile or unit test failure would toss the staging repo contents back so that the mainline was not polluted.

All well and fine - except for bug reports.  When a developer marked a bug as fixed, there was a good chance QA would re-open it soon thereafter because the fix wasn't in their mainline-based build yet.  So developers routinely would add copious "Fixed in SHA-1 in staging repo blah, branch foo" comments to ward off bugs being reopened too soon.

With a git-based system, the update to the ticket could be made in the staging repo as well.  The mainline repo's copy of the ticket will still show "not fixed", but once the staging repo passes CI, the ticket changes will be merged as well.  At all times, the tickets reflect an accurate picture of what is in each staging repo and mainline.

The ticgit system isn't perfect though.  I'd actually prefer the tickets to be stored in the master branch, so that the commit that fixes the bug in the source code also updates the ticket state.  It is common to update the source code, documentation, and unit tests in a single SHA1 - there's no reason why the ticket state change couldn't be made part of the commit as well.