Re: [RFC] git integrated bugtracking

[Rogan Dawes <lists@dawes.za.net>]

Martin Waitz wrote:
> 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