Каков синтаксис опции git clone --filter?

Git 2.17 changelog описывает эту опцию:

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

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

git clone file://path --depth=1 --filter '--subdirectory-filter Assets' TestRepo
git clone file://path --depth=1 --filter --subdirectory-filter Assets TestRepo
git clone file://path --depth=1 --filter Assets TestRepo

3 ответа

Решение

Формат для спецификации фильтра определен в разделе опций git rev-list --help, Вы также можете увидеть это на github. Вот что он говорит в данный момент:

--filter =<фильтр-спецификации>

Полезно только с одним из --objects*; пропускает объекты (обычно капли) из списка печатных объектов. может быть одним из следующих:

Форма --filter=blob:none опускает все капли.

Форма --filter=blob:limit=<n>[kmg] опускает BLOB-объекты размером более n байтов или единиц. п может быть ноль. Суффиксы k, m и g могут использоваться для именования единиц в KiB, MiB или GiB. Например, blob:limit=1k - это то же самое, что blob:limit=1024.

Форма --filter=sparse:oid=<blob-ish> использует спецификацию sparse-checkout, содержащуюся в BLOB-объекте (или выражении BLOB-объекта) , чтобы пропустить BLOB-объекты, которые не потребуются для редкой проверки на запрошенных ссылках.

Форма --filter=sparse:path=<path> аналогичным образом используется спецификация sparse-checkout, содержащаяся в .

Этот вариант менее полезен, чем я надеялся. (Его нельзя использовать для объединения клона и ответвления фильтра.

И все же этот механизм фильтрации является расширением механизма, связанного с клоном, для реализации частичного клонирования (или узкого клона), представленного в декабре 2017 года в Git 2.16.

Но ваш хостинг-сервер Git-репо должен поддерживать протокол v2, поддерживаемый на данный момент (октябрь 2018) только GitLab.

Это означает, что вы можете использовать --filter с git clone, как показывает недавний патч Git 2.20 (см. ниже).

Затем этот фильтр был добавлен в git fetch в этой серии патчей.
Это часть новой возможности протокола пакета " filter ", добавлено в согласование fetch-pack и upload-pack.
См. "Фильтр" в Documentation / technical / pack-protocol, который ссылается на опции rev-list.

В Git 2.20 (Q4 2018) частичный клон, настроенный на ленивый выбор отсутствующих объектов, по запросу выдаст сообщение " git fetch msgstr "запрос в исходный репозиторий для заполнения еще не полученных объектов.
Запрос был оптимизирован для запроса объекта дерева (а не объектов конечного блоба, содержащихся в нем), сообщая исходному хранилищу, что капли не нужны.

См. Коммит 4c7f956, коммит 12f19a9 (03 октября 2018 г.) Джонатана Тана ( jhowtan )
(Объединено Юнио С Хамано - gitster - в комитете fa54ccc, 19 октября 2018 г.)

fetch-pack: исключать сгустки при ленивых деревьях

Частичный клон с отсутствующими деревьями можно получить с помощью git clone --filter=tree:none <repo> ".
В таком хранилище, когда дерево нужно лениво извлекать, любое дерево или большой двоичный объект, на которые он прямо или косвенно ссылается, выбирается также независимо от того, требовали ли эти объекты исходная команда или если в локальном хранилище уже были некоторые из них.

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

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

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

Вы можете увидеть дальнейшую оптимизацию с:

См. Коммит e70a303, коммит 6ab4055, коммит 0177565, коммит 99bcb88 (27 сентября 2018 г.) от Jonathan Tan ( jhowtan )
(Объединено Юнио С Хамано - gitster - в комитете 0527fba, 19 октября 2018 г.)

транспорт: разрешить пропуск реф ссылки

get_refs_via_connect() Функция выполняет как рукопожатие (включая определение версии протокола), так и получение списка удаленных ссылок.

Тем не менее, протокол выборки v2 поддерживает выборку объектов без перечисления ссылок, поэтому пользователь может пропустить перечисление, создав новый handshake() функция.

: подмодуль редакция.

(см. мой предыдущий ответ для обычного репозитория git clone --filter)

Понятие частичного клона для подмодуля (разреженная проверка) начало появляться:

В Git 2.29 (4 квартал 2020 г.) этот ленивый / частичный clone --filter работает даже с подмодулем, когда transfer.fsckobjects установлен.

См. (20 августа 2020 г.) .
(Объединено в коммите 63728e4, 31 августа 2020 г.)

Commit 1b03df5: в частичном клоне пройти

Подписано: Джонатан Тан

При загрузке пакета с удаленного устройства Promisor необходимо создать соответствующий файл.
"" изначально сделал это, передав "" в "", но в (": записать полученные ссылки в .promisor", 2019-10-16, Git v2.25.0-rc0 - слияние указано в пакете №1) " fetch-pack "научили делать это самому, потому что ему нужно было хранить справочную информацию в файле.

Это вызывает проблему с суперпроектами при установке transfer.fsckobjects, потому что в текущей реализации это "" вызывает проверку объектов; до 5374a290aa5374a290aa , увидит, что это объект-обещание, и допустит его отсутствие, но после этого нет .promisor файл (во время вызова fsck_finish() ""), чтобы сказать, что .gitmodules является промисорным объектом, поэтому возвращает ошибку.

Поэтому учите «сдавать» --promisor"чтобы снова проиндексировать пакет.
" "впоследствии перезапишет этот файл справочной информацией.

Альтернативный вариант - вместо этого переместить проверку объекта в " fetch-pack", и пусть" "только индексирует файлы.
Однако, поскольку" index-pack"должен раздувать объекты, чтобы индексировать их, кажется разумным также позволить ему проверять объекты (для чего также требуются завышенные файлы).


В Git 2.33 (3 квартал 2021 г.) подготовьте внутреннее устройство для ленивого извлечения объектов в подмодулях с их удаленных промизоров.

См. , commit d1fa943, commit 69bb2e1, commit ef7dc2e, commit ebaf3bc (17 июня 2021 г.) Джонатан Тан ()Джонатан Тан ( jhowtan) .
(Слияние Junio ​​C Hamano - -Junio ​​C Hamano - gitster- в коммите 8721e2e, 16 июля 2021 г.)

Commit ef830ccpromisor-remote: научить lazy-fetch в любом репо

Подписано: Джонатан Тан
Рецензент: Элайджа Ньюрен

Это один из шагов к поддержке подмодулей частичного клонирования.

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

Другие вопросы по тегам