Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > How would that work with existing versions? If you write -2 in > cache-tree, the next time 1.8.0 updates cache tree it writes -1 back. > That loses whatever information you attach to -2. A new cache-tree > extension is probably better. You can easily imagine a definition like this: - If non-negative, the entry is valid and it is the number of index entries that are covered by this subtree; - If -1, the cached-tree does not know the object name of the tree object, and nothing else is known. The caller needs to walk the index to skip the entries that could have been covered by this subtree, if the cached tree information were valid; - If less than -1, the cached-tree does not know the object name of the tree object, but we know the number of index entries that are covered by this subtree. The caller, instead of walking the index, can subtract the count from -1 and skip that many entries to find the index entry after the part that is inside this directory. Newer Git may write -201 and newer Git may be able to take advantage of the new information encoded there, saving 200 calls to prefixcmp(), while given the same index, older Git will operate just as correctly as before. An older Git may write that part of the cache-tree back with -1, defeating the optimization when a newer Git reads it back, but by definition the older Git does not know what to write to help that optimization that did not exist when it was done, and writing -1 will not confuse the newer Git. -- 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