git submodule реализован в виде сценария оболочки, поэтому легко увидеть, что он делает - он может быть на /usr/lib/git-core/git-submodule, если вы используете упакованную версию. По сути, он просто запускает git-fetch в подмодуле, если имя объекта (SHA1sum), хранящееся в дереве основного проекта, не совпадает с версией, извлеченной в подмодуле, поскольку Koraktor указывает .
В документации для git fetch (или man git-fetch, когда kernel.org не работает) говорится, что он должен извлекать каждый тег, указывающий на загруженный объект, и загруженные объекты будут включать каждый коммит, который предок каждой ветви, которая выбрана. Это означает, что для меня удивительно, что вы не получаете все соответствующие теги на git submodule update.
Если вы действительно хотите, чтобы ваш сценарий пытался установить новую версию субмодуля и зафиксировать этот результат, я не думаю, что 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 на всякий случай ваш тег не тот, который указывает на загруженный коммит.)
Очевидно, что есть еще одна возможность - указать подмодуль на коммите, на который указывает тег, а не на сам тег, но это не выглядит аккуратно.
Ну, единственное, что хранится в дереве основного проекта для подмодуля, это просто хеш объекта коммита, поэтому даже если бы была команда, которая говорила «установить мой подмодуль на тег my-tag в этом подмодуле» в конечном итоге все равно будет храниться хеш, соответствующий этому тегу ...