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

[Junio C Hamano <junkio@cox.net>]

Johan Herland <johan@herland.net> writes:

> On Monday 28 May 2007, Linus Torvalds wrote:
>> 
>> On Mon, 28 May 2007, Johan Herland wrote:
>> > 
>> > I still don't see what makes note objects inherently more expensive than
>> > commit objects. Except for the refs, of course, but we're getting rid
>> > of those (at least replacing them with a more efficient reverse mapping).
>> 
>> It's exactly the refs that I worry about.
>> 
>> Anything that needs to read in all notes at startup is going to be _slow_.
>> 
>> In contrast, commits we read when (and only when) we need them.
>
> Ok. But the reverse mapping will help with this, won't it?
> We'll look up the interesting commits and find their associated
> note objects directly.

The issue Linus brought up worries me, too.

The "efficient reverse mapping" is still handwaving at this
stage.  What it needs to do is an equivalent to your
implementation with "refs/notes/<a dir per commit>/<note>".  The
"efficient" one might do a flat file that says "notee note" per
line sorted by notee, or it might use BDB or sqlite, but the
amount of the data and complexity of the look-up is really the
same.  A handful notes per each commit in the history (I think
Linus's "Acked-by after the fact" example a very sensible thing
to want from this subsystem).

I am not saying that it is impossible to make the set-up cost
for the "efficient lookup" almost zero, and to make it lazy and
on-demand.  The concern above just adds one design constraints
to that "efficient reverse mapping" code yet to come.