"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > 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. You are a brave person to say this (no sarcasm --- I wish I were, too). On one hand, I very much applaud and appreciate your comment for injecting sanity to the discussion. On the other hand, if Linus had such an attitude, we might not be hacking on git right now. After looking at the above existing alternatives, some brave soul might decide and say, "Hey, I can write something better in 2 weeks" ;-). > 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 All of your examples are going from a single bug to commits, but from a release person's point of view, you are never interested in a single bug, just like a top-level maintainer is never interested in a single file. A release person would want to go in the reverse direction: from a commit range to a set of bugs. What bugs were fixed and what regressions were introduced during this release cycle. While embedded ticket numbers in commit log messages would certainly help, a change made to fix a particular bug may fix another as its side effect, and the develeoper who did the change may not know about the latter when the commit log message is written. > 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. These are indeed very good points. - 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
