Re: [RFC] git integrated bugtracking

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jun 10, 2007, 06:59 UTC
Message-ID: <46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com>
In-Reply-To: <20070609121244.GA2951@artemis>

On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:

Show 5 quoted lines

>   FWIW I've begun to work on this (for real). I've called the tool
> "grit". You can follow the developpement on:
>
>   * gitweb: http://git.madism.org/?p=grit.git;a=summary
>   * git:    git://git.madism.org/grit.git/

Call me a fool, but writing a <new> bugtracker looks like a boil-the-oceans scheme.

Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is what is going to make the difference. Most of those have already the ability to "link" to one or more commits -- after the commits are done and in GIT.

So you can tell your bugtracker
 - which commit fixed it -- usually auto-linked if you include the
bugnumber in the commit message
 - which commit added the test -- auto linked as above
 - which commit introduced the bug -- if such thing exists and someone
digs it up

If the bugtracker can also auto-link things that look committish in text entered by users (someone might write "bisect sez that f345e is to blame"), with tooltips indicating in which heads those commits resides (like gitk does), then it's just gorgeous.

But I would _never_ try to describe all the possible relations in the schema -- existing trackers use a liberal mix of regexes and cache tables with some free form text fields for this kind of stuff.

And definitely, if you use git as an alibi to write a new bugtracker, don't use the "works only with git" as a feature. It should work with as many SCMs as possible.

OTOH, that's just me, I'm lazy and like to work on already-successful projects that are 99% there for my needs (and where I can add that 1%).

cheers,