Резюме:
Пакетные файлы Git тщательно сконструированы для эффективного использования дискового кэша и
обеспечить «хорошие» шаблоны доступа для общих команд и для чтения недавно упомянутых ссылок
объекты.
Git's pack file
формат довольно гибкий (см. Documentation / technical / pack-format.txt ,
или Packfile в The Git Community Book ).
Файлы пакета хранят объекты в двух основных
способы: «не определено» (взять необработанные данные объекта и сжать-сжать)
это), или «delified» (образуют дельту против какого-то другого объекта, то
дефляция-сжатие результирующих дельта-данных). Объекты, хранящиеся в
пачка может быть в любом порядке (они не обязательно должны быть)
отсортированы по типу объекта, имени объекта или любому другому атрибуту) и
Различающиеся объекты могут быть сделаны против любого другого подходящего объекта того же типа.
Команда Git pack-objects использует несколько эвристик для
предоставить отличную местность ссылки для общего пользования
команды. Эти эвристики контролируют как выбор базы
объекты для делитифицированных объектов и порядок объектов. каждый
Механизм в основном независим, но у них есть общие цели.
Git формирует длинные цепочки дельта-сжатых объектов, но
эвристика пытается убедиться, что только «старые» объекты находятся на концах
длинные цепи Кэш дельта-базы (размер которого контролируется
core.deltaBaseCacheLimit переменная конфигурации) автоматически
используется и может значительно сократить количество «перестроений», необходимых для
Команды, которые должны прочитать большое количество объектов (например, git log
-p).
Дельта-сжатие Эвристический
Типичный репозиторий Git хранит очень большое количество объектов, поэтому
он не может разумно сравнить их все, чтобы найти пары (и
цепочки), которые дадут наименьшее дельта-представление.
Эвристика выбора дельта-базы основана на идее, что
Хорошие дельта-базы будут найдены среди объектов с похожими именами файлов.
и размеры. Каждый тип объекта обрабатывается отдельно (т.е.
Объект одного типа никогда не будет использоваться в качестве дельта-базы для
объект другого типа).
В целях выбора дельта-базы объекты сортируются (в основном) по
имя файла, а затем размер. Окно в этот отсортированный список используется для ограничения
количество объектов, которые рассматриваются как потенциальные дельта-базы.
Если «достаточно хорошее» 1 дельта-представление не найдено для объекта
среди объектов в своем окне, то объект не будет дельта
сжатая.
Размер окна определяется параметром --window=
git pack-objects или переменная конфигурации pack.window.
Максимальная глубина цепи дельта контролируется --depth=
опция git pack-objects или конфигурация pack.depth
переменная. --aggressive опция git gc значительно расширяется
размер окна и максимальная глубина, чтобы попытаться создать
файл меньшего размера.
Сортировка имен файлов объединяет объекты для записей с
идентичные имена (или, по крайней мере, похожие окончания (например, .c)). Размер
сортировка от самой большой до самой маленькой, так что дельты, которые удаляют данные,
предпочтительнее дельты, которые добавляют данные (так как удаление дельты имеют более короткие
представления) и тем, что раньше, более крупные объекты (обычно
новее), как правило, представлены с простым сжатием.
1
То, что считается «достаточно хорошим», зависит от размера рассматриваемого объекта и его потенциальной дельта-базы, а также от того, насколько глубокой будет его итоговая дельта-цепь.
Объектный порядок эвристики
Объекты хранятся в файлах пакета в «самой последней ссылке»
порядок. Объекты, необходимые для реконструкции новейшей истории:
размещены ранее в пакете, и они будут близко друг к другу. это
обычно хорошо работает для дисковых кешей ОС.
Все объекты фиксации отсортированы по дате фиксации (сначала самая последняя)
и хранятся вместе. Такое размещение и порядок оптимизации диска
доступы, необходимые для прогулки по историич и извлечь базовый коммит
информация (например, git log).
Объекты дерева и блоба сохраняются, начиная с дерева из
первый сохраненный (самый последний) коммит. Каждое дерево обрабатывается в глубину
Первая мода, хранение любых объектов, которые еще не были
сохраняются. Это помещает все деревья и капли, необходимые для реконструкции
самый последний коммит вместе в одном месте. Любые деревья и капли, которые
еще не были сохранены, но которые необходимы для последующих коммитов
сохраняется в отсортированном порядке фиксации.
Окончательный порядок объектов слегка зависит от выбора дельта-базы
в том случае, если объект выбран для дельта-представления и его базового объекта
еще не был сохранен, то его базовый объект сохраняется непосредственно перед
сам объект Это предотвращает возможные ошибки дискового кэша из-за
необходим нелинейный доступ для чтения базового объекта, который «естественно»
сохраняется в файле пакета.