Junio C Hamano <gits...@pobox.com> writes:

>> +== Design explanations
>> + ...
>> +[3] The data of the cache-tree extension and the resolve undo
>> +    extension is now part of the index itself, but if other extensions
>> +    come up in the future, there is no need to change the index, they
>> +    can simply be added at the end.
> Interesting.  When we added extensions, we said that there is no
> need to change the index to add new features, they can simply be
> added at the end.  Perhaps the file offset table can be added as an
> extension to v2 to give us the same bisectability, allowing us a
> single entry in-place replacementability, without defining an
> entirely different format?

Just to avoid wasting people's time, in case they try to respond to
this part which was tongue-in-cheek.

There is a valid technical reason why the above cannot be done with
the original index format and why a new extension does not make
sense. There is no quick way to locate the extensions section in the
file without reading all the entries first, so by the time you know
where the extensions are, you already know all the paths, and have
enough information to build a table necessary to do the bisection
without a separate data in a new extension.

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

Reply via email to