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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Mon, 28 May 2007, Shawn O. Pearce wrote:

> Junio C Hamano <junkio@cox.net> wrote:
> > Johan Herland <johan@herland.net> writes:
> > > 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).
> 
> Please, don't use BDB or sqllite.  I really don't trust either.
> I've lost data to both.  I've *never* lost data to a Git packfile.
> ;-)

Also, there is the question of dependencies. We don't have to repeat SVN's 
errors.

As for sqllite: the only reason I was _not_ horrified when I realized that 
cvsserver needs sqllite was that it is not really important for the 
common user.

> I'm actually thinking pack v4.  OK, I know its just a virtual hand
> waving thing still, but there's really no reason Nico and I cannot
> get the damn thing finished before we both wind up buying the farm.

Maybe I am missing something important here, but I think we do not at all 
need a generic database here. Just a key/value store.

As it happens, we already have such a beast. It is called object store 
here.

Now, the only reason we cannot do something like "SHA-1 ^ 0xff[...]ff" is 
the SHA-1 for the note for that commit, is that you could possibly have 
more than one note for the commit.

Of course, without that restriction, we could reuse our object store logic 
for notes.

Side note: the more I think about this notes thing, the more I get 
disgusted by the deep changes we'd have to do just to accomodate for them. 
Are they really worth it? Or would something like a pseudo-branch suffice, 
being one strand of notes (commits), where the second commit parent is 
actually the commit the note is for?

Ciao,
Dscho