Что такое git тонкие пакеты?

Ответ 1

Для записи в man-странице (index-pack) указано:

Возможно, для git-pack-objects создать "тонкий" пакет, который записывает объекты в дефинированной форме на основе объектов, включен в пакет для снижения сетевого трафика.
Эти объекты должны присутствовать на принимающей стороне, и они должны быть включены в пакет для того, чтобы этот пакет был автономным и индексируемым.

Это завершит git push справочную страницу параметра --thin:

Тонкая передача тратит дополнительные циклы, чтобы минимизировать количество отправляемых объектов и предназначалось для использования при более медленном подключении

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

В этот поток, Якуб Нарбскиски объясняет немного больше (в контекст использования git gc на удаленной стороне, а также на локальной стороне):

Git выполняет делит только в packfiles.
Но когда вы нажимаете SSH, git будет генерировать пакетный файл с фиксацией другой стороны, и эти пакеты являются тонкими пакетами, поэтому у них также есть дельта... но удаленная сторона добавляет базы к тем тонким пакетам, что делает их автономными.

Точнее:

На местной стороне:
git-commit создает свободные (сжатые, но не деликатные) объекты. git-gc упаковывает и делит.

На удаленной стороне (для интеллектуальных протоколов, т.е. git и ssh):
git создает тонкий пакет, deltified,
на удаленной стороне git либо делает пакет толстым/автономным, добавляя базовые объекты (объект + дельта), либо взрывает пакет в свободный объект (объект).
Вам нужно git -gc на удаленном сервере, чтобы полностью делить на удаленную сторону. Но передача полностью deltified.

На удаленной стороне (для немых протоколов, т.е. rsync и http):
git находит необходимые пакеты и передает их целиком.
Таким образом, ситуация похожа на локальную сторону, но git может передавать больше, чем нужно, потому что она полностью передает пакеты.

Проблема выше была связана с использованием (или неприменением) git push --thin: когда вы его используете или нет?
Оказывается, вам нужно тщательно управлять своими двоичными объектами, если вы хотите, чтобы git использовал эти тонкие пакеты:

• Создайте новое имя файла, просто скопировав старый (так используется старый blob)
• совершить
• PUSH
• скопируйте настоящий новый файл
• совершить
• PUSH.

Если вы опустите средний PUSH на шаге 3, ни "git push", ни "git push --thin", может понять, что этот новый файл может быть "инкрементно построен" на удаленной стороне (даже если git -gc полностью выкалывает его в пакете).

Фактически, тонкие пакеты работают, чтобы хранить дельта против базового объекта, который не включен в пакет.
Те объекты, которые не включены, но используются в качестве базы дельта, в настоящее время представляют собой только предыдущую версию файла, который является частью обновления, которое нужно нажать или извлечь.
Другими словами, для этого должна существовать предыдущая версия под тем же именем.
Выполнение иначе не будет масштабироваться, если предыдущая фиксация имела тысячи файлов для тестирования.

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

Ответ 2

Примечание git 1.8.5 (Q4 2013):

Вы думаете, что отключение тонкой опции будет с push -no-thin?
Вы ошибаетесь до 1.8.5:

"git push --no-thin" фактически отключает оптимизацию "тонкой передачи пакетов".

Смотрите зафиксировать f7c815c для всех деталей gory, благодаря "pclouds" - Nguyễn Thái Ngọc Duy:

push: respect --no-thin

• В начале push.c в 755225d, 2006-04-29, опция thin" была включена по умолчанию, но можно отключить с помощью --no-thin.

• Затем Shawn изменил значение по умолчанию на 0 в пользу сохранения ресурсов сервера в a4503a1, 2007-09-09. --no-thin работал отлично.

• Через день, в 9b28851, Daniel выделил код push.c для создания transport.c. Он (вероятно, случайно) перевернул значение по умолчанию от 0 до 1 в transport_get().

С этого момента --no-thin эффективно не работает, потому что git-push все еще ожидает, что значение по умолчанию будет ложным, и вызывает только transport_set_option(), когда переменная "thin" в push.c равна true (что нет необходимости).
Исправьте код, чтобы уважать --no-thin, вызывая transport_set_option() в обоих случаях.

receive-pack узнает о --reject-thin-pack-for-testing опции, которая предназначена только для целей тестирования, следовательно, обновление документа.

Ответ 3

Я понимаю, что это оптимизация для передачи объектов между двумя репозиториями.

Я думаю, вы использовали бы его только при реализации собственных git служб, не использующих пакет отправки и получения.