Shawn Pearce <spearce@xxxxxxxxxxx> writes: > Junio C Hamano <junkio@xxxxxxx> wrote: > [snip] >> +A new style .idx file begins with a signature, "\377tOc", and a >> +version number as a 4-byte network byte order integer. The version >> +of this implementation is 2. > > Ick. I understand why you did this (and thanks for such a good > explanation of it by the way) but what a horrible signature number > and way to wedge in a version number. I do not think it is particularly horrible. I initially was planning to introduce a new file extention .toc (table of contents), not just because that would let us start afresh with file format that has version number from the beginning, but also because we use the word "index" to mean "cache" these days, and it would be a good idea to use a different word to mean different things. The latter 3 bytes reflects that. > I think we probably should have done this when the binary headers > were introduced into loose objects. No. That was purely .pack format and did not affect .idx format. Honestly .idx is purely a local matter and not as important to keep stable as the .pack format. > Sure the scheme you outlined allows a 64 bit difference but > uncompressed objects already can't be larger than 2**32-1... Where do we have that limitation? In any case, the next round I am planning to get rid of this "where the tail is" business. I do not think it buys us much and inflates the 46MB index you need to deal with even more. I think your "allow zlib to eat the remainder of the current window and slide window when it exhausts the current window" logic is a very good on and makes it unnecessary to know the tail of each object. -- VGER BF report: U 0.5 - 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