Re: Git Notes idea.

On Wed, Dec 17, 2008 at 12:48:02AM +0100, Johannes Schindelin wrote:

quoted

Perhaps I am missing something, how is it a linear search?

Yes, you are missing what I wrote in the original thread: tree objects 
must be read in a forward direction, one by one.

Thanks, that was a nice writeup of what was discussed at the
GitTogether.

Peff's very cute idea was to decouple that process from the per-commit 
procedure, and basically make it a one-time cost (per Git call, and only 
when notes were asked for).

To be fair, it was not my cute idea, but somebody else's (I think David
Reiss). I just coded it quickly because somebody was talking about
iPhones or something. :)

To the contrary.  When I rebase, the tree _does_ change, otherwise I
would have rebased onto something that had the same original tree as
my rebase-base to begin with, which would make the rebase rather
pointless.

Another fun option would be to put notes on patch-ids. That would of
course be horrifically slow to look up, but would survive many
cherry-picks and rebases (but not all, of course).

I don't know if that is useful or not, but I don't see any reason why
the discussed implementation would forbid it (somebody would just have
to implement the lookups at a useful spot).

quoted

On naming.  I strongly support a ref/notes/sha1/sha1 approach.

I think you meant refs/notes:<first byte in hex>/<rest of bytes>/<some
arbitrary SHA-1>?

You seem to be in favor of the fan-out. Out of curiosity, did you ever
do numbers on whether the fan-out is actually helpful?

I am rather supporting refs/nots:<first byte in hex>/<rest of bytes>
being either a blob, or a tree containing human readable tags, such as
"bugfix" or "review" or some such.

Yes, I am in favor of the "tree or blob" idea, too. I want this to not
just be about "I am a person writing a note" but "arbitrary data
attached to an object after it has been created". And that means
thinking up front about managing the namespace.

-Peff