Каковы тонкие пакеты мерзавца?

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

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

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

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

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

Подробнее см. " Git fetch для многих файлы работает медленно по сравнению с диском с высокой задержкой ».

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

Точнее:

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

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

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

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

1. Создайте новое имя файла, просто скопировав старое (чтобы использовался старый blob)
2. commit
3. PUSH
4. скопировать настоящий новый файл
5. commit
6. PUSH.

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

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

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