On 6/10/07, Pierre Habouzit <madcoder@xxxxxxxxxx> wrote:
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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
