Confusion about the PACK format

* Confusion about the PACK format
@ 2019-02-10 16:02 Florian Steenbuck
  2019-02-10 19:05 ` Ramsay Jones
  0 siblings, 1 reply; 4+ messages in thread
From: Florian Steenbuck @ 2019-02-10 16:02 UTC (permalink / raw)
  To: git

Hello to all,

I try to understand the git protocol only on the server site. So I
start without reading any docs and which turns to be fine until I got
to the PACK format (pretty early failure I know).

I have read this documentation:
https://raw.githubusercontent.com/git/git/c4df23f7927d8d00e666a3c8d1b3375f1dc8a3c1/Documentation/technical/pack-format.txt

But their are some confusion about this text.

The basic header is no problem, but somehow I got stuck while try to
read the length and type of the objects, which are ints that can be
resolved with 3-bits and 4-bits. The question is where and how ?

I try to parse the int from the beginning of the bits:
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
1 - 3 = type
4 - 7 = len
(I using a python way to convert it to a int which is equal to:
int('{0:08b}'.format(raw_objects[offset])[x:y], 2)
)
As mentioned in the doc n is part of the len calculation. Question of
interest why ? And what is n ?
I interpreted it as the type as it is a number and prefixed with n-byte.

This requires me to do one more step:
len = (type-1)*len

Which ends in a endless loop, because my byte offset never hits the
end of, caused by often type that is 0.

I then try to interpret it in a different way so I now take two bytes
and on every byte I take the end of the bits for get the type and len:

byte a (equal to [offset+0])
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
6 - 8 = type

byte b (equal to [offset+1])
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
5 - 8 = len

Which in my case stops the endless loop, but seems to not get correct
typing, zero and five types appears everywhere, and not get the
correct size of the object, I use the length that I calculate before.
Their are multiple errors that appears while try to decompress the
data.

Now to complete other topic error handling, what is the suggest way to
handle a type 0 or type 5 and what is with type < 0 and type > 5 ?

Type 0 is invalid, should the parsing fail here ?
Type 5 is reserved for future expansion, where should we continue then ?

Also I do not understand this:
`a negative relative offset from the delta object's position in the
pack if thisis an OBJ_OFS_DELTA object`
What relative offset I need to check here ?

Kind Regards
Florian

^ permalink raw reply	[flat|nested] 4+ messages in thread