Re: More precise tag following

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