Re: [PATCH v2] index-format.txt: be more liberal on what can represent invalid cache tree

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 13, 2012, 01:55 UTC
Message-ID: <7v8v921zt6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1355361287-10875-1-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy  <pclouds@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.