Re: [RFC] git integrated bugtracking

From: david@lang.hm <david@lang.hm>
Date: Jun 3, 2007, 17:35 UTC
Message-ID: <Pine.LNX.4.64.0706031031520.6705@asgard.lang.hm>
In-Reply-To: <20070603160736.GC30347@artemis>

On Sun, 3 Jun 2007, Pierre Habouzit wrote:

Show 22 quoted lines

> On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:
>> Pierre Habouzit <madcoder@debian.org> 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