Важно
При выполнении перепаковки обязательно используйте -F, чтобы:
Передать параметр --no-reuse-object в git-pack-objects
как документация git repack отмечает, и вы обнаружили. В противном случае ваш новый уровень сжатия не будет применяться ни к каким существующим объектам.
Фон
Существует три регулятора:
core.compression устанавливает значения по умолчанию для обоих core.loosecompression и pack.compression. Если это не задано явно, остальные два остаются с их настройками или настройками по умолчанию. core.loosecompression устанавливает сжатие zlib по умолчанию. Если не установлено, по умолчанию используется собственное значение zlib «лучшая скорость». pack.compression устанавливает сжатие пакета по умолчанию. Если он не установлен, по умолчанию используется собственный уровень сжатия по умолчанию в zlib (который может зависеть от вашего zlib, но я думаю, что обычно он равен 6; см. https://www.euccas.me/zlib/).
Но в пакетных файлах уровень сжатия может быть гораздо менее значимым для окончательного размера файла пакета. Причина этого в том, что файл пакета формата ... ну, вот ссылка на техническую документацию , но я бы суммировал это как , как правило, с преобладанием дельты В цепочках вместо обычно преобладает содержимое файла .
свободный объект состоит из дефлированного по zlib заголовка Git и необработанного содержимого файла. Здесь сжатие (и уровень), как правило, будет иметь тот же эффект, что и если бы вы делали собственное сжатие zlib, поскольку заголовок довольно мал по сравнению с обычным файлом, и эти байты не должны мешать поиску подстроки. Весь объект сжимается без учета каких-либо других объектов.
A упакованный объект, однако, может быть либо базовым объектом , либо обособленным объектом . Если упакованный объект является базовым объектом, его сжатие может быть аналогичным сжатому объекту. Но если упакованный объект разграничен, он будет состоять из двоичных инструкций, а не из текста. Они вряд ли сжимаются очень хорошо.
Предположим, что ваша средняя дельта-цепочка имеет длину 20 объектов. Это означает, что для каждого базового объекта существует 19 разделенных объектов. Предположим, что сжатие работает очень хорошо (скажем, до 35% от исходного размера) для базового объекта, и ужасно (скажем, до 97% от исходного размера) для делитированных объектов. Предположим далее, что средний размер базового объекта составляет 64 КБ, а средний размер объекта с разделителями, включая инструкции, составляет 6,4 КБ. Тогда улучшение этих показателей, скажем, до 32% и 94% соответственно - что может быть реалистичным c, но я не проводил никаких фактических измерений - отнимет у нас:
- Оригинал: 35% ( 65536) + 19 * (97% (6554)) = 22938 + 19 * 6537 = 147141
- уровень 9: 32% (65536) + 19 * (94% (6554)) = 20972 + 19 * 6161 = 138031
Это не такой большой выигрыш, как мы могли ожидать: свободный объект уменьшился бы примерно на 8,5%, а файл пакета уменьшился примерно на 6,5%.
(Результаты было бы интересно провести различные эксперименты по упаковке реальных данных Git, а не эти мысленные эксперименты. Еще более интересным может быть использование некоторых других алгоритмов сжатия, упомянутых в первой ссылке выше.)