On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > > > 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpE7bgz0msO6.pgp
Description: PGP signature
