Junio C Hamano <gitster@xxxxxxxxx> wrote: > I've long time ago concluded that if we care about reliability > (and we do very much), a bisectable tree without breaking > backward compatibility is impossible. I was hoping to find a > "hole" in tree object format so that I can place an extended > section that is invisible to older versions of git, and place a > table that records offsets of each tree entries to help > bisection and/or perhaps a hash table to help look-up, but I do > not think it is possible. ... > But the tree object format > is designed so tight that I do not see there is any place to put > an extension section. I came to the same conclusion the last time I thought about this problem, for all the same reasons you outlined. And came up with pack v4. Because the only way I could see that we could produce a more optimal tree was to just use a different *compression* of the tree, while still keeping its data the same. Nico seemed to agree at the time, because he worked on the prototype with me. :-) Its still hanging around in my fastimport repository. But has not been merged with any recent Git, and it still needs a lot of work. -- Shawn. - 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
