On Sun, 3 Jun 2007, Pierre Habouzit wrote:
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.
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
-
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
