Hi, On Tue, 10 Feb 2009, Shawn O. Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > On Tue, 10 Feb 2009, Junio C Hamano wrote: > > > > > > I could do a revert on 'master' if it is really needed, but I found that > > > the above reasoning is a bit troublesome. The thing is, if a tree to hold > > > the notes would be huge to be unmanageable, then it would still be huge to > > > be unmanageable if you split it into 256 pieces. > > > > The thing is, a tree object of 17 megabyte is unmanagably large if you > > have to read it whenever you access even a single node. Having 256 trees > > instead, each of which is about 68 kilobyte is much nicer. > > See my other email on this thread; we'd probably need to unpack > all 256 subtrees *anyway* due to the distribution of SHA-1 names > for commits. No, that is not true. It is only true if you show more than 94180 commit, actually, as only then the probability that you hit all 256 buckets is larger than 50 percent. In general, you will look at only a few commits, though. Ciao, Dscho -- 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
