Каковы тонкие пакеты мерзавца?
Я не нашел много информации о тонких упаковках, и информация на страницах руководства довольно загадочна по этому поводу. Я знаю, что это как-то связано с медленными соединениями, но что такое "медленное соединение"?
Каковы его плюсы и минусы? Когда я должен использовать это, когда я не должен использовать это?
3 ответа
Для справки, справочная страница ( index-pack
) говорится:
Это возможно для
git-pack-objects
создать "тонкий" пакет, который записывает объекты в разделенной форме на основе объектов, не включенных в пакет, для уменьшения сетевого трафика.
Ожидается, что эти объекты будут присутствовать на приемном конце, и они должны быть включены в пакет, чтобы этот пакет был автономным и индексируемым.
Это завершило бы git push
справочная страница --thin
опция:
Тонкая передача тратит дополнительные циклы, чтобы минимизировать количество отправляемых объектов и предназначена для использования при медленном соединении
Таким образом, "медленная сеть" в данном случае - это соединение, в которое вы хотите отправить как можно меньше данных.
Смотрите больше на " Git fetch для многих файлов медленнее на диске с высокой задержкой ".
В этой теме Jakub Narębski объясняет немного больше (в контексте использования git gc на удаленной стороне, а также на локальной стороне):
Git делает делитификацию только в пакетных файлах.
Но когда вы проталкиваете через SSH, git генерирует файл пакета с коммитами, которых у другой стороны нет, и эти пакеты являются тонкими пакетами, поэтому они также имеют дельты...
но удаленная сторона затем добавляет базы к этим тонким пакетам, делая их автономными.
Точнее:
На местной стороне:
git-commit
создает свободные (сжатые, но не разграниченные) объекты.git-gc
пакеты и деликатесы.На удаленной стороне (для интеллектуальных протоколов, т.е. git и ssh):
мерзавец создает тонкую пачку, очищенную;
на удаленной стороне git либо делает пакет плотным / самодостаточным, добавляя базовые объекты (объект + дельты), либо взрывает пакет в незакрепленный объект (объект).
Вам нужен git-gc на удаленном сервере, чтобы полностью удалить на удаленной стороне. Но перевод полностью отграничен.На удаленной стороне (для тупых протоколов, т.е. rsync и http):
Git находит нужные пакеты и передает их целиком.
Таким образом, ситуация похожа на локальную, но git может передавать больше, чем нужно, потому что он передает пакеты полностью.
Вышеуказанная проблема была связана с использованием (или неиспользованием) git push --thin
: когда вы используете это или нет?
Оказывается, вам нужно тщательно управлять вашими двоичными объектами, если вы хотите, чтобы git воспользовался этими тонкими пакетами:
- Создайте новое имя файла, просто скопировав старое (поэтому используется старый блоб)
- совершить
- ОТ СЕБЯ
- скопировать настоящий новый файл
- совершить
- ОТ СЕБЯ.
Если вы опустите средний PUSH на шаге 3, ни
git push
"ни"git push --thin
"может понять, что этот новый файл может быть" построен постепенно "на удаленной стороне (даже если git-gc полностью уничтожит его в пакете).Фактически, способ, которым работают тонкие пакеты, состоит в том, чтобы хранить дельту против базового объекта, который не включен в пакет.
Те объекты, которые не включены, но используются в качестве дельта-базы, в настоящее время являются только предыдущей версией файла, который является частью обновления, которое будет отправлено / извлечено.
Другими словами, для этого должна быть предыдущая версия с тем же именем.
В противном случае масштабирование не будет выполнено, если предыдущий коммит будет иметь тысячи файлов для проверки.Эти тонкие пакеты предназначены для разных версий одного и того же файла, а не для разных файлов с почти одинаковым содержимым. Проблема заключается в том, чтобы решить, какую предпочтительную дельта-базу добавить в список объектов. В настоящее время рассматриваются только объекты с тем же путем, что и изменяемые.
Примечание из Git 1.8.5 (4 квартал 2013 года):
Вы могли бы подумать, что отключение опции thin будет с push --no-thin?
Вы были бы не правы до 1.8.5
" git push --no-thin
msgstr "фактически отключает оптимизацию" передачи тонких пакетов ".
См. Commit f7c815c для всех кровавых деталей, благодаря "pclouds" - Nguy Thn Thái Ngọc Duy:
толчок: уважение --no-thin
С начала
push.c
в 755225d, 2006-04-29 "thin
"опция была включена по умолчанию, но могла быть отключена с помощью--no-thin
,Затем Шон изменил значение по умолчанию на
0
в пользу экономии ресурсов сервера в a4503a1, 2007-09-09.--no-thin
работал отлично.Однажды, в 9b28851, Даниил извлек некоторый код из
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
опция, которая только для целей тестирования, следовательно, нет обновления документа.
Насколько я понимаю, это оптимизация для передачи объектов между двумя хранилищами.
Я думаю, что вы будете использовать его только при реализации своих собственных git-сервисов без использования пакетов send и receive.