Re: [RFC] git integrated bugtracking

From: Rogan Dawes <lists@dawes.za.net>
Date: Jun 4, 2007, 09:32 UTC
Message-ID: <4663DC16.8080309@dawes.za.net>
In-Reply-To: <20070603230702.GC16637@admingilde.org>

Martin Waitz wrote:

Show 18 quoted lines

> hoi :)
> 
> On Sun, Jun 03, 2007 at 10:16:32PM +0200, Pierre Habouzit wrote:
>>   Well I went that way, but we loose the quite cool "if I branch my
>> repository I branch the bugs coming with them too"-feature. And I'd be
>> sad to give that up. But maybe it's an error to want to use git to
>> encode that relation.
> 
> Just store the commit which introduced the bug (or where the bug
> was first found) and you will get that, too.  You only have to check
> if this commit is reachable by a given branch to see if it is affected.
> When you fix the bug you store the commit id that fixed it and then
> you can check every branch if it points into bad..good.
> 
> You can also do this for released versions.
> If you have the bug database inside the repository you can't report
> any bugs for a released version, because it is, well already released.
>

Ok, that seems reasonable.

Now, how do you store updates to a bug? i.e. followup questions and answers?

As suggested in another message, I think that the bug id would have to be the hash of the initial report (incl whatever metadata is considered interesting).

I think that the individual reports might be stored by their id, perhaps via a fan out dir, like the .git/objects directory. Attachments can be stored by their hash in a separate directory structure. Modifications to a report would simply be appended to the original report. Simultaneous modifications could be dealt with by merging the two files, probably using a custom merge driver.

Obviously the format of a bug report and follow up message would need to be quite strictly defined and adhered to, for the merge driver to be able to do its work with the minimum/zero user interaction.

Closed bugs would be deleted from the filesystem, but would obviously be available via the history.

Indexes or categories could be implemented by means of symlinks/symrefs in a different set of "index directories". e.g.

/categories/drivers/deadbeef -> ../../bugs/de/adbeef /assignedto/joe@example.org/deadbeef -> ../../bugs/de/adbeef

or similar. These might not be strictly necessary, since all that information will be in the report anyway. Perhaps the indexes would be stored simply as cached data, and rebuilt if out of date.

The porcelain would then take care of presenting the bugs to the user in the preferred format, much like we have gitk, gitweb, qgit, tig, etc.

Does any of this make sense?

Rogan