Блог

Допустим, у меня есть три репозитория, child , parent и grandparent . parent имеет подмодуль child и grandparent имеет два подмодуля parent и child .

Чего я хочу добиться, так это того, что parent проверка выполняется (или инициализация и обновление) child только тогда, когда parent само по себе является автономным репозиторием (а не подмодулем другого репозитория). И когда parent это подмодуль of grandparent , он не будет проверять свой собственный child , но будет использовать child предоставленный by grandparent . Причина, по которой я это делаю, заключается в том, что child и parent являются большими базовыми репозиториями, и grandparent являются листовыми. Итак, существует много разных grandparent репозиториев, каждый из которых имеет свой подмодуль, указывающий на разные коммиты в child и parent . И поскольку child он большой, я не хочу хранить еще одну его копию parent . Если быть более точным, child это репозиторий активов, содержащий все виды данных и активов. parent является анализатором данных. И grandparent является ли приложение, использующее анализатор для доступа к ресурсам. Поскольку разные приложения имеют несколько разный прогресс в принятии изменений, внесенных в репозиторий данных и анализатора, мне нужно добавить «дочерний» и «родительский» в качестве подмодулей напрямую grandparent , чтобы получить лучший контроль над исходным кодом, вместо того child , чтобы просто сидеть parent и быть parent подмодулем. И я также хочу parent , чтобы у него была своя собственная копия child , потому что разработка parent является автономной и не зависит ни grandparent от кого.

Файловая структура из трех репозиториев будет

 grandparent
|-- src
|-- include
|-- submodules
    |-- parent
        |-- src
        |-- include
        |-- submodule
            |-- child (trying to make this one not being checked out here)
    |-- child (this one should be checked out)

parent
|-- src
|-- include
|-- submodules
    |-- child (this one should be checked out)

child
|-- audio
|-- video
|-- pics
|...
 

Возможно ли достичь того, что я описал? Или что было бы наилучшей практикой в таком сценарии.

Учитывая (обновленную) картинку, я бы посоветовал избегать рекурсивного режима подмодуля и просто вручную (или по сценарию?) Выполнять любые необходимые git submodule update команды в рабочем дереве grandparent репозитория. То есть:

 git clone $url grandparent
cd grandparent
git submodule update --init
 

В .gitmodules (найденном grandparent/.gitmodules после git clone и .gitmodules после cd команды) будет указан URL-адрес для submodules/parent и submodules/child . Проверка, выполненная в новом grandparent каталоге, созданном git clone , когда git clone достигает последнего шага клонирования (проверка), заполнит как индекс Git, так и ваше рабочее дерево, так что submodules/parent и submodules/child у обоих есть идентификатор хэша, записанный в индексе. Тогда git submodule update --init он поймет, что ему нужно запустить две git clone git checkout команды and для заполнения submodules/parent and submodules/child .

Поскольку рекурсия отключена (и git submodule update не указано, чтобы включить ее), клон parent оставляет неклонированный подмодуль: submodules/parent/submodule/child на данный момент это просто пустой каталог. Пока никто не запускает команду:

 (cd submodules/parent amp;amp; git submodule update --init)
 

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