On Wed, Dec 17, 2008 at 12:48:02AM +0100, Johannes Schindelin wrote: > > 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). > > 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 -- 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
