On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:
quoted text
>   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,


m
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html