Ответ 1
git submodule реализуется как оболочка script, поэтому легко увидеть, что он делает - он может быть в /usr/lib/git-core/git-submodule, если вы используете упакованную версию. По сути, он просто запускает git-fetch в подмодуле, если имя объекта (SHA1sum), хранящееся в основном дереве проекта, не соответствует версии, проверенной в подмодуле, поскольку указывает Корактор.
Документация для git fetch (или man git-fetch в то время как kernel.org не работает) говорит, что она должна извлекать каждый тег, который указывает к загруженному объекту, и загруженные объекты будут включать в себя все фиксации, которые были бы предком каждой ветки, которая была извлечена. Это означает, что мне удивительно, что вы не получаете все соответствующие теги на git submodule update.
Если это так, то, что вы действительно хотите, для вашего script заключается в попытке установить новую версию подмодуля и зафиксировать этот результат, я не думаю, что git submodule update - это инструмент, который вы хотите - это просто для обеспечения того, чтобы ваши подмодули находились в правильной версии, исходя из того, что в настоящее время происходит в основном проекте. Вместо этого вы должны просто сделать что-то вроде:
( cd my-submodule && \
git fetch && \
git fetch --tags && \
git checkout my-tag )
git add my-submodule
git commit -m 'Update the submodule to the "my-tag" version' my-submodule
(я добавил дополнительный git fetch --tags на всякий случай ваш тэг не тот, который указывает на загруженный фиксатор.)
Очевидно, есть еще одна возможность - указать субмодуль на фиксацию, на которую указывает тэг, а не на сам тег, но это не выглядит так аккуратно.
Ну, единственное, что хранится в главном дереве проекта для подмодуля, - это всего лишь хэш объекта commit, поэтому даже если бы была команда, которая сказала: "Установите мой подмодуль тегу my-tag в этом подмодуле", это в конечном итоге просто сохранило бы хэш, соответствующий этому тегу...