Nguyễn Thái Ngọc Duy <pclo...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html