Блог

Я прохожу курс git, изучаю объекты git.

Не совсем понятно, почему каждый объект git хранит метаданные так, как он это делает.

Каждый объект добавляет заголовок:

 header = "blob #{content.length}"
 

По-видимому, существует 4 типа объектов git:

• Большой двоичный объект
• Дерево
• Фиксация
• Аннотированный тег

Это 4 возможных варианта или 2 бита данных. Даже с учетом будущего расширения, это можно было бы превратить в один байт, добавленный к каждому объекту.

Зная, что первый байт всегда будет типом, и имея файловую систему, сообщающую вам длину файла, вы можете легко вычислить длину данных в объекте как file_size - 1 byte . Это устраняет необходимость в поле длины или разделителе, поскольку ваши метаданные теперь имеют постоянную длину.

Даже при текущем дизайне, где поле типа представляет собой строку переменной длины, зная размер файла объекта, который вам сообщит файловая система (например, ext4), и длину заголовка, которую вы можете определить, прочитав до и включив разделитель, кажется, что вы можетелегко вычислить длину данных, хранящихся внутри объекта ( file_size - header_length ).

Есть ли причина, по которой Торвальдс (или кто-то еще) решил использовать строку для представления типа объекта, чтобы включить длину содержимого (которую можно вычислить) и включить разделитель?

Я тоже могу только догадываться *, но наиболее вероятной причиной будет: надежность.

Зная, что первый байт всегда будет типом, и имея файловую систему, сообщающую вам длину файла

Предполагается, что данные поступают из файла и что файловая система верна!

Что делать, если файловый объект не был полностью записан на диск (недостающие байты) или по какой-либо причине содержит дополнительные данные (дополнительные байты)? При явно указанной ожидаемой длине эти условия ошибки легко обнаруживаются и иногда даже исправляются.

С другой стороны, явные длины позволяют легко объединять несколько объектов и считывать / передавать их в потоке (например, в память, по сети — хотя это скорее использует формат пакета).

Кроме того, — с точки зрения программиста — знание размера объектов заранее позволяет выделить буферы соответствующего размера перед чтением объектов с диска и т. Д.

_{* Возможно, это должен был быть комментарий, поскольку это не настоящий ответ, но я почувствовал, что он слишком длинный для комментария}