Как сделать субмодуль sparse-checkout с помощью Git?
Есть много статей и ТАК вопросов о sparse-checkout. К сожалению, я не нашел конкретных примеров. Я хотел бы получить следующий пример работы:
Создать подмодуль
cd ~
mkdir sub && cd $_
git init
mkdir foo && touch $_/foo
mkdir bar && touch $_/bar
git add .
git commit -am "Initial commit"
Создать проект
cd ~
mkdir project && cd $_
git init
git submodule add ../sub sub
git config -f .gitmodules submodule.sub.shallow true
git config -f .gitmodules submodule.sub.sparsecheckout true
echo foo/* > .git/modules/sub/info/sparse-checkout
git commit -am "Initial commit"
git submodule update
cd sub
git checkout .
А этот момент я ожидаю sub папка должна содержать только foo/foo не bar, К сожалению, это не работает:
$ ls
bar/ foo/
Как я могу заставить это работать?
1 ответ
git submodule add Сам проверяет субмодуль.
То, что удалось для меня, было:
git init
# I did not find a way to add submodule in 1 step without checking out
git clone --depth=1 --no-checkout ../sub sub
git submodule add ../sub sub
git submodule absorbgitdirs
# note there is no "submodule.sub.sparsecheckout" key
git -C sub config core.sparseCheckout true
# note quoted wildcards to avoid their expansion by shell
echo 'foo/*' >>.git/modules/sub/info/sparse-checkout
git submodule update --force --checkout sub
Начиная с Git 2.25 (первый квартал 2020 г.), вы должны использовать новую команду git sparse-checkout
А с Git 2.28 (3 квартал 2020 г.) эффект sparse checkout задокументированы настройки подмодулей.
См. Commit e7d7c73 (10 июня 2020 г.) Элайджа Ньюрен (newren).
(Слияние Junio C Hamano -gitster- в коммите 81be89e, 22 июня 2020 г.)
git-sparse-checkout: прояснить взаимодействия с подмодулямиПодписано: Элайджа Ньюрен Автор отзыва
: Деррик Столи
Игнорирование функции разреженной проверки на мгновение, если у кого-то есть подмодуль и внутри него создаются локальные ветки с невытесненными изменениями и, возможно, к нему добавляются неотслеживаемые файлы, тогда мы бы хотели избежать случайного удаления такого подмодуля.
Так, например, с git.git, если вы запустите
git checkout v2.13.0тогда подмодуль sha1collisiondetection НЕ удаляется, даже если он не существовал как подмодуль до v2.14.0.
Точно так же, если вы ранее проверяли только версию 2.13.0 и запускали
git checkout v2.14.0подмодуль sha1collisiondetection НЕ будет автоматически инициализирован, несмотря на то, что он является частью v2.14.0.
В обоих случаях git требует, чтобы подмодули инициализировались или деинициализировались отдельно.
Кроме того, у нас также есть специальная обработка подмодулей в других командах, таких как clean, для чего требуется два
--forceфлаги для удаления неотслеживаемых подмодулей, а некоторые команды имеют--recurse-submodulesфлаг.sparse-checkout очень похож на checkout, о чем свидетельствует похожее название - он добавляет и удаляет файлы из рабочей копии.
Однако по тем же причинам, что и во избежание потери данных, мы не хотим удалять подмодуль из рабочей копии с помощью checkout, мы не хотим делать это и с sparse-checkout.
Таким образом, субмодули необходимо отдельно инициализировать или деинициализировать; изменение правил разреженной проверки не должно автоматически приводить к удалению или оживлению подмодулей.
Я верю предыдущей формулировке в
git sparse-checkoutabout submodules был только об этой конкретной проблеме.К сожалению, предыдущая формулировка может быть истолкована как подразумевающая, что субмодули следует считать активными независимо от моделей разреженности.
Обновите формулировку, чтобы избежать такого предположения.
Было бы полезно рассмотреть два примера ситуаций, когда различия в формулировках становятся важными:
В будущем мы хотим, чтобы пользователи могли запускать такие команды, как
git clone --sparse=moduleA --recurse-submodules $REPO_URLи иметь автоматическую настройку разреженных путей и автоматическую инициализацию подмодулей в разреженных путях.
Мы не хотим, чтобы все подмодули на любом пути автоматически инициализировались этой командой.
Точно так же мы хотим иметь возможность делать такие вещи, как
git -c sparse.restrictCmds grep --recurse-submodules $REV $PATTERNи поиск по
$REVза$PATTERNв записанных моделях разреженности.Мы хотим, чтобы он рекурсивно распределялся по подмодулям внутри этих шаблонов разреженности, но не хотим рекурсивно переходить в каталоги, которые не соответствуют шаблонам разреженности, в поисках возможного субмодуля.
Итак, документация теперь включает:
Если ваш репозиторий содержит один или несколько подмодулей, то подмодули заполняются на основе взаимодействий с
git submoduleкоманда.
В частности,git submodule init -- <path>обеспечит подмодуль на<path>присутствует, в то время какgit submodule deinit [-f] -- <path>удалит файлы для подмодуля в<path>(включая любые неотслеживаемые файлы, незафиксированные изменения и неотслеживаемую историю).
Подобно тому, как sparse-checkout удаляет файлы из рабочего дерева, но по-прежнему оставляет записи в индексе, деинициализированные подмодули удаляются из рабочего каталога, но по-прежнему имеют запись в индексе.Поскольку в субмодулях могут быть неопубликованные изменения или неотслеживаемые файлы, их удаление может привести к потере данных.
Таким образом, изменение правил разреженного включения / исключения не приведет к удалению уже извлеченного подмодуля из рабочей копии.
Сказал по-другому, так же какcheckoutне приведет к автоматическому удалению или инициализации подмодулей даже при переключении между ветвями, которые удаляют или добавляют подмодули, используяsparse-checkoutуменьшение или расширение области "интересных" файлов также не приведет к автоматической деинициализации или инициализации подмодулей.Кроме того, приведенные выше факты означают, что существует несколько причин, по которым "отслеживаемые" файлы могут не присутствовать в рабочей копии: приложение шаблона разреженности из разреженной проверки и состояние инициализации подмодуля.
Таким образом, такие команды, какgit grepработа с отслеживаемыми файлами в рабочей копии может возвращать результаты, ограниченные одним или обоими этими ограничениями.