Re: [RFC] git integrated bugtracking

On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:

Pierre Habouzit [off-list ref] writes:

quoted

  Yeah, now that I read that thread, well yeah, I think notes are a hell
of a good concept for my ideas. I mean, a bug report would be basically
a collection of notes:
  * the bug has been found at this commit ;
  * the bug has been not-found at this commit ;
  * this commit is a fix for that bug ;

That's my feeling too. "Commiting" bug information in the tree is only
half of a good idea. You want to be able to say, after the fact, "This
commit had bug XYZ". OTOH, the idea (followed by bugs everywhere) that
merging a branch would automatically close bugs fixed by this branch
is a really cool thing.

  That would work with notes, as while merging you'll get the notes of
the commit in your branch, *and* the note about the fixing patch. So
there is no loss of "concept" here. In fact that was the thing that I
looked for. Notes are good. They just may not be enough to write an
in-git bugtracking tool, as a bug needs the "notes collection" concepts,
and maybe a few other.

The kind of information you're mentionning above can be a great
starting point for "bisect". I can even imagine a kind of distributed
bisect, where several users could give their "bad commits" for the
same bug.

  Heh yes. Sometimes it's more complex than that as bugs can come back
(regressions) or be the result of many commits (like the cases that suck
with bisect). For a complex bug it's more a set of [found..notfound[
intervals. Though this indeed is very valuable information, and the
distributed component thing *is* great.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org