частичное клонирование

Механизм для клиента для описания ненужных или нежелательных объектов серверу.

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

Механизм для клиента для корректной обработки отсутствующих объектов (которые были предварительно исключены сервером).

Механизм для клиента для заполнения отсутствующих объектов по мере необходимости.

Новая возможность протокола пакетов «фильтр» добавляется к переговорам fetch-pack и upload-pack.

Это использует существующий механизм обнаружения возможностей. См. «фильтр» в gitprotocol-pack[5].

Клиенты передают «спецификацию фильтра» для клонирования и получения, которая передается серверу для запроса фильтрации во время построения пакетов.

Доступны различные фильтры, чтобы удовлетворить различные ситуации. См. «--filter=<filter-spec>» в Documentation/rev-list-options.txt.

На сервере pack-objects применяет запрошенную спецификацию фильтра, создавая «отфильтрованные» пакеты для клиента.

Эти отфильтрованные пакеты являются неполными в традиционном смысле, потому что они могут содержать объекты, которые ссылаются на объекты, не содержащиеся в пакете и которые у клиента еще нет. Например, отфильтрованный пакет может содержать деревья или теги, которые ссылаются на отсутствующие blobs или коммиты, которые ссылаются на отсутствующие деревья.

На клиенте эти неполные пакеты помечаются как «пакеты-обеспечители» и обрабатываются различными командами по-разному.

Для локального репозитория добавляется расширение конфигурации, чтобы предотвратить сбой старых версий git во время операции из-за отсутствующих объектов, с которыми они не могут справиться. См. extensions.partialClone в git-config[1].

Объект может отсутствовать из-за частичного клонирования или получения, или из-за повреждения репозитория. Чтобы отличить эти случаи, локальный репозиторий специально указывает такие отфильтрованные пакеты, полученные от удаленных репозиториев-обеспечителей, как «пакеты-обеспечители».

Эти пакеты-обеспечители состоят из файла «<name>.promisor» с произвольным содержимым (например, файлы «<name>.keep»), помимо файлов «<name>.pack» и «<name>.idx».

Локальный репозиторий рассматривает «объект-обеспечителя» как объект, о котором он знает (насколько ему известно), что удаленные репозитории-обеспечители пообещали, что у них есть, либо потому, что локальный репозиторий имеет этот объект в одном из своих пакетов-обеспечителей, либо потому, что другой объект-обеспечителя на него ссылается.

Когда Git сталкивается с отсутствующим объектом, Git может проверить, является ли он объектом-обеспечителем, и обработать его соответствующим образом. В противном случае Git может сообщить о повреждении.

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

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

Когда обычный поиск объекта не находит объект, Git вызывает promisor_remote_get_direct(), чтобы попытаться получить объект из удаленного репозитория-обеспечителя, а затем повторить поиск объекта. Это позволяет объектам «загружаться по запросу» без сложных алгоритмов предсказания.

Из соображений эффективности не выполняется проверка, является ли отсутствующий объект на самом деле объектом-обеспечителем.

Динамическая загрузка объектов, как правило, медленная, так как объекты загружаются по одному.

checkout (и любая другая команда, использующая unpack-trees) научилась предварительно загружать все необходимые отсутствующие blobs в одной партии.

rev-list научилась печатать отсутствующие объекты.

Это можно использовать другим командам для предварительной загрузки объектов в пакет. Например, «git log -p A..B» может внутри сначала выполнить что-то вроде «git rev-list --objects --quiet --missing=print A..B» и предварительно загрузить эти объекты в пакет.

fsck была обновлена, чтобы полностью учитывать объекты-обеспечителя.

repack в GC была обновлена, чтобы вообще не касаться пакетов-обеспечителей и переупаковывать только другие объекты.

Глобальная переменная «fetch_if_missing» используется для управления тем, будет ли поиск объекта пытаться динамически загрузить отсутствующий объект или сообщить об ошибке.

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

Загрузка объектов выполняется путем вызова подпроцесса «git fetch».

Локальный репозиторий отправляет запрос с хэшами всех запрашиваемых объектов и не выполняет никаких переговоров о пакете. Затем он получает пакет.

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

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

extensions.partialClone = <name>

remote.<name>.promisor = true

remote.<name>.partialCloneFilter = ...

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

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

Невозможно отправить только определенные объекты в удаленный репозиторий-обеспечителя.

Невозможно одновременно отправлять в несколько удаленных репозиториев-обеспечителей в определенном порядке.

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

Переупаковка в основном обрабатывает пакеты-обеспечители и пакеты, не являющиеся пакетами-обеспечителями, как 2 отдельных раздела и не смешивает их.

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

Динамическая загрузка объектов в настоящее время использует существующий протокол пакетов V0, что означает, что каждый объект запрашивается через fetch-pack. Сервер отправит полный набор info/refs при установлении подключения. Если есть большое количество refs, это может привести к значительной нагрузке.

Улучшить способ указания порядка, в котором будут пробоваться удаленные серверы promisor.

Например, это позволит явно указать: «При получении данных с этого удаленного сервера я хочу использовать эти удалённые серверы promisor в этом порядке, однако при отправке или получении данных на тот удаленный сервер я хочу использовать эти удаленные серверы promisor в другом порядке».

Разрешить отправку данных на удаленные серверы promisor.

Пользователь может захотеть работать в треугольной рабочей схеме с несколькими удаленными серверами promisor, каждый из которых имеет неполное представление о репозитории.

Разрешить фильтрацию, не основанную на пути, для использования битовых карт packfile (если они доступны). Это была просто ошибка при первоначальной реализации.

Исследовать использование долговременного процесса для динамического получения ряда объектов, как предложено в [5,6], чтобы уменьшить затраты на запуск процесса и накладные расходы.

Было бы неплохо, если бы протокол pack версии 2 позволил этому долговременному процессу выполнять серию запросов через одно долговременное подключение.

Исследовать протокол pack версии 2, чтобы избежать трансляции информации/ссылок при каждом подключении к серверу для динамического получения отсутствующих объектов.

Исследовать необходимость обработки разрозненных объектов promisor.

Объекты в файлах promisor packfile могут ссылаться на отсутствующие объекты, которые можно динамически получить с сервера. Было предположено, что разрозненные объекты создаются только локально и, следовательно, не должны ссылаться на отсутствующий объект. Возможно, нам придётся пересмотреть это предположение, если, например, мы динамически получим отсутствующее дерево и сохраним его как разрозненный объект, а не в отдельном файле packfile.

Это не обязательно означает, что нам нужно помечать разрозненные объекты как promisor; может быть достаточно ослабить функции поиска объектов или функции «is-promisor».

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

Никакой работы по этому вопросу не проводилось; мы просто документируем, что это распространённое предложение. Мы не уверены, как это будет работать, и у нас нет планов работать над этим.

Сервер может отправлять больше объектов, чем запрошено (даже для динамического получения объектов), но мы не разрабатываем это.