On Fri, 28 Oct 2011, Shawn Pearce wrote: > On Fri, Oct 28, 2011 at 15:48, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Fri, 28 Oct 2011, Shawn Pearce wrote: > >> - The immediate next byte encodes the extended type. This type is > >> stored using the OFS_DELTA offset varint encoding, and thus may be > >> larger than 256 if we ever need it to be. > > > > I'd say it is just a byte. No encoding needed. Let's not be silly > > about it. If we really have more than 255 object types one day (and I > > really hope this will never happen) then the value 0 in that byte could > > indicate yet another extended object type encoding. But I truly hope > > we'll have pack v9 or v10 by then and that we'll have obsoleted the > > current 3-bit encoding completely at that point anyway. > > Yes. I probably wouldn't code the parser to use a varint here. I would > say the extended types stored in this byte must be >= 8, and must be > <= 127. Any values out of this range are unsupported and should be > rejected. We can later reserve the right to set the high bit and > switch to the OFS_DELTA varint encoding if we need that many more > types, and we explicitly define codes 0-7 as illegal if detected here > in the extended byte field. I wouldn't go as far as rejecting codes 1-7 as illegal though, but I otherwise agree with what you say. Nicolas