Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html