Re: [RFC] git integrated bugtracking

On Sun, 3 Jun 2007, Pierre Habouzit wrote:

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

quoted

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.

how would you identify bugs in such a way that they will match up when you 
merge different trees?

if you can manage to do this it sounds like a great idea. but I'm not 
seeing a good way to do it at the moment. the answer may be a combination 
of a number of factors.

1. bug number doesn't work well in a distributed environment

2. something based on indentifying the cause of the bug (commit id + file 
+ line????) will only work after you know the real cause of the bug

3. description is worthless, too many ways to describe things that have 
the same underlying cause

David Lang