On Sat, 27 Jan 2007, Junio C Hamano wrote: > Anything you would do, storing that in tree is wrong. Tree > object only represents just the contents of a single state and > in itself there should not be any information that describes its > relation with other trees [*1*]. > > And of course making it pack-only is doubly wrong. > > > *1* That's why my thinking-aloud talked about "N list of changed > paths recorded in a commit object with N parents". A commit is > to talk about one particular state (i.e. tree) and its relation > to other commits (and by indirection, other trees), so logically > the information could belong there --- that is merely a "could", > since that is strictly caching for performance. After finding > where the bottleneck is, obviously finding a way to optimize the > tree pathlimiting with the currently available data without > having such redundant data is more preferable. I do think, too, that such data is not desirable in the object database. However there is nothing wrong with a separate "cache", just like the pack index, that can be discarded and recreated at any time. Especially since this "cache data" might change with time as new tricks to speed up things are found. OTOH it is preferable to keep the object database as slick and stable as possible. Nicolas - 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