Re: [PATCH 00/15] git-note: A mechanisim for providing free-form after-the-fact annotations on commits

[Andy Parkins <andyparkins@gmail.com>]

On Tuesday 2007 May 29, Linus Torvalds wrote:

> So you'd have to have a separate database. You could do it with a separate
> index file (or mixing it up with the "index v4" and doing it with a single
> index file that also contains normal objects), but the point is, it's
> going to be a real separate database.

This is an off-the-wall suggestion; but why not use the object database a bit 
more strongly than just for storing the notes?  The original method was to 
use the filesystem to store refs/notes/$SHA1, which was essentially annotated 
tags.  The object database has been designed for storing thousands of 
hierarchically organised files, so why not use that instead of the refs/ 
tree?

That is to say, make a "private" branch, independent of any real repository 
branches.  I'll call it "notes".  Then each commit in that branch represents 
a change to a note (or multiple notes).  The tree attached to each commit 
provides the reverse lookup that's wanted, and also maps to the object 
itself.  So where a normal tree has

100644 blob 156e952df8603c72532bcda95ddcd3bcb16ec5fd somefile

A "notes" tree would have

100644 blob 156e952df8603c72532bcda95ddcd3bcb16ec5fd $SHA1_OF_TARGET_COMMIT1
100644 blob 97e08b0ab483146cb8fff31138eaa828c24ac84f $SHA1_OF_TARGET_COMMIT2

All the "notes" tools could now use the standard git tools to look up a note.  
The notes would be version controlled (which is impressive in itself), and 
reverse lookup is the same as path-limited git-rev-list.

The tree objects are (I guess) stored alphabetically, so the reverse lookup 
could be done with a binary search.  If a user really wanted to, they could 
check out the "notes" branch and edit the files directly.

Madness?  I'm sure.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com