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@xxxxxxxxx - 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
