On Wed, Aug 8, 2012 at 11:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > The current code that access nth entry from the index->cache[nth] > would need to be updated to use an accessor function, whether the > "nth" comes from index_name_pos() or from the for-loop that iterates > over the entire index. For the latter, you would need to give the > users a function that returns a cursor into the in-core index to > allow iterating over it. > > When you use an in-core representation that is not a flat array, the > type of "nth", which is essentially a cursor, may have to change to > something that is richer than a simple integer, in order to give the > implementation of the in-core index a more efficient way to access > the entry than traversing the leaves of the tree depth first, and > you would need to update index_name_pos() to return such a "cursor". > That design and development cost is part of updating the in-core > data structure. In the end result, the runtime cost to manipulate an > index entry that the cursor refers to should be minimum, as that > would be the cost paid by all the users of the API anyway, even if > we _were_ starting from an ideal world where there weren't any flat > in-core index in the first place. Interesting. So you hide the entire tree walk behind the cursor concept. And we can make pathspec filter as part of cursor initialization. Index iteration code this way looks really neat (compared to how we do traverse sha-1 trees nowadays). The hard part is updating the index while iterating (or avodiing running into such a situation). Maybe C++ STL has done it already with std::map::iterator. I fear that by hiding the trees, we might miss some optimization opportunities. But I haven't figured it all out yet so I may be wrong. -- Duy -- 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