Git: значение объекта 'size', возвращаемое git verify-pack

Question

Команда git verify-pack имеет опцию -v, которая выводит много диагностической информации для каждого объекта, найденного в файле pack. Однако значение, возвращаемое полем size для дефинированного объекта, не соответствует моим туманным ожиданиям - я думал, что это будет что-то вроде несжатого «истинного» размера объекта Git? Каков фактический смысл этой области?

В частности, у меня есть packfile Git, который содержит большой объект:

$ git cat-file -s 7daa9e75f86aa168748aef6c16c76b2acee1acca 
61464170 

(т.е. размер объекта составляет около 58MB, что на самом деле то, что я вижу, когда я проверить файл из)

Тем не менее, линия возвращается для этого объекта посредством git verify-pack -v заключается в следующем:

7daa9e75f86aa168748aef6c16c76b2acee1acca blob 568352 529608 770759074 1 27e47895a3822906eb31b05fe674ad470296c12e 

(Полная копия вывода проверить-пакет доступен here)

Как вы можете видеть (после прочтения the documentation для git verify-pack), этот объект хранится deltafied и определение столбцов это:

SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1 

Так «размер» для этого объекта (и «размер-в-packfile» является 529608) - но что это значит, учитывая, что фактический размер объекта является байт? Разница в величине величины в размере должна означать, что цифра размера относится только к дельта?

Answer 1

Первый, см. this diagram. Затем, на основе источника (builtin/index-pack.c), значение в четвертом поле:

(unsigned long)(obj[1].idx.offset - obj->idx.offset) 

, который является исходным уплотненным до размера (obj[1] является следующим объектом после того, как этот, или прицеп). Поскольку сохраненный элемент делит, это размер данных с дельта-сжатием плюс накладные расходы. Значение в третьем поле - obj->size (значение первого размера из верхней области).

(Чтобы получить фактические данные, или даже его размер, вы должны раздуть этот поток немного, а затем посмотреть на заголовки дельта. «Истинный» размер объекта кодируется в заголовке в качестве второго значения размера См. get_size_from_delta в sha1_file.c, get_delta_hdr_size в delta.h, и «смещение кодирования» на диаграмме)

---

Изменить, чтобы добавить:. OK, перечитывая вопрос, вы спрашиваете о том, почему четвертый размер настолько меньше третьего. Это было бы потому, что третий - это завышенный (но не де-треугольник) размер объекта. Итак: size-in-packfile (поле 4) после дефляции, но также содержит бит служебных данных заголовка; размер дельта-сжатого файла (поле 3), очевидно, очевиден; и размер конечного файла после отмены дельта-сжатия находится в заголовке, счетчик байтов которого включен в файл размера в пакете (поле 4).

Дополнительное редактирование: файл offset-in-packfile (поле 5) равен obj->idx.offset.Вот где у вас должно быть lseek() в файле пакета, чтобы начать читать объект (я думаю, у меня есть какой-то запутанный код передо мной для обработки OBJ_OFS_DELTA тоже :-)).

Answer 2

Был недавний патч серии [RFC/PATCH 0/4] cat-file --batch-disk-sizes обсуждение, которое включало "[PATCH 07/10] cat-file: add %(objectsize:disk) format atom", которое может представлять интерес, если вы хотите скомпилировать исходный код.