Re: Mozilla .git tree

From: Junio C Hamano <>
Date: 2006-09-02 21:02:50
Shawn Pearce <> writes:

> Junio C Hamano <> 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
More majordomo info at
Received on Sat Sep 02 21:03:43 2006

This archive was generated by hypermail 2.1.8 : 2006-09-02 21:04:20 EST