On Thursday 27 August 2009, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > Yea, it was me. I still think it might be a useful idea, since > > it allows you better density of loading notes when parsing the > > recent commits. In theory the last 256 commits can easly be in > > each of the 2/ fanout buckets, making 2/38 pointless for reducing > > the search space. Commit date on the other hand can probably force > > all of them into the same bucket, making it easy to have the last > > 256 commits in cache, from a single bucket. > > > > But I thought you shot it down, by saying that we also wanted to > > support notes on blobs. I happen to see no value in a note on > > a blob, a blob alone doesn't make much sense without at least an > > annotated tag or commit to provide it some named context, and the > > latter two have dates. > > Yeah, and in this thread everybody seems to be talking about commits so I > think it is fine to limit notes only to commits. Agreed. I'm starting to come around to the idea of storing them in subtrees based on commit dates. For one, you don't have multiple notes for one commit in the same notes tree. Also, the common-case access pattern seems tempting. Dscho: Were there other problems with the date-based approach other than not supporting notes on trees and blobs? If not, I'll start preparing another series with the date-based approach. Thanks for the input, guys. :) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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