Как обновить только определенные подмодули git?

Ответ 1

Я заканчиваю там поиском того, как обновлять только определенный подмодуль, что означает для меня, обновляя подмодуль в ref, указанный его супер-репо. Это не вопрос и не ответ, а только название.

Итак, в надежде помочь некоторым другим, подобным мне, ответ на вопрос:

git submodule update <specific path to submodule>

который поместит этот подмодуль в состояние ref, записанное в супер-репо.

Ответ 2

Собственно, правильный синтаксис:

$ git clone <remote.git>
$ cd <remote>
$ git submodule update --init -- <specific relative path to submodule>

Ответ 3

Если вы только что клонировали репо с подмодулями, вы можете клонировать определенный подмодуль с помощью:

git submodule update --init submoduleName

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

Ответ 4

Из документации подмодуля git

--remote Эта опция действительна только для команды обновления. Вместо того, чтобы использовать суперпроекты, записанные SHA-1, для обновления субмодуля, используйте статус ветки удаленного отслеживания субмодулей. Используется удаленный филиал (branch..remote), по умолчанию используется источник.

Для обновления конкретного подмодуля вы можете использовать:

git submodule update --remote <path to the submodule>

В вашем случае это должно быть:

git submodule update --remote bundle/syntastic

Ответ 5

Как мне обновить конкретный подмодуль, расположенный, скажем, в bundle/syntastic, без обновления каких-либо других подмодулей?

С помощью Git 2.13 (и с помощью submodule.<name>.update config):

git clone --recurse-submodules="bundle/syntastic"
git config submodule.syntastic.update "git pull origin master"

Вторая строка (должна выполняться только один раз) необходима, потому что команда clone --recurse-submodules[=<pathspec] эквивалентна выполнению git submodule update --init --recursive <pathspec> сразу после завершения клона.
И это только оформило бы подмодуль в его записанном SHA1 gitlink, а не в самом последнем SHA1 удаленного origin/master.
Добавляя submodule.<name>.update конфигурации submodule.<name>.update, вы гарантируете, что за выборочным клоном подмодуля последует обновление, только для этого подмодуля.

В рамках функции активного субмодуля Git 2.13 (Q2 2017) (см. " Игнорировать новые коммиты для git submodule ") у вас есть этот коммит bb62e0a от Брэндона Уильямса (bmwill):

clone: научить --recurse-submodules опционально использовать спецификацию пути

Научите --recurse-submodules опционально принимать аргумент pathspec, который описывает, какие подмодули должны быть рекурсивно инициализированы и клонированы.
Если путь не указан, --recurse-submodules будут рекурсивно инициализировать и клонировать все подмодули, используя путь по умолчанию " . ".
Для построения более сложных спецификаций пути --recurse-submodules могут быть заданы несколько раз.

Это также настраивает " submodule.active опцию" конфигурации быть дано pathspec, таким образом, что любое будущее вызов git submodule update будет идти в ногу с pathspec.

Кроме того, переключатель " --recurse " удален из документации, а также помечен как скрытый в массиве опций, чтобы упростить опции для подмодулей. Простое " --recurse " не передает то, что повторяется, например, оно может означать каталоги или деревья (см. ls-tree).
Во многих других командах у нас уже есть " --recurse-submodules ", что означает повторение в подмодули, поэтому рекламируйте это написание здесь как подлинную опцию.

Итак, страница руководства git clone --recursive теперь гласит:

--recurse-submodules[=<pathspec]:

После того, как клон создан, инициализируйте и клонируйте подмодули в пределах на основе предоставленной спецификации пути.

Если путь не указан, все подмодули инициализируются и клонируются.

Подмодули инициализируются и клонируются с использованием настроек по умолчанию.
Полученный клон имеет submodule.active набор к предоставленной pathspec, или " " (то есть все подмодули), если нет pathspec не предусмотрено. .
Это эквивалентно запуску git submodule update --init --recursive сразу после завершения клона. Эта опция игнорируется, если клонированное хранилище не имеет рабочего дерева/извлечения (т.е. Если задано какое-либо из --no-checkout/-n, --bare или --mirror)

Пример из теста t/t7400-submodule-basic.sh:

git clone --recurse-submodules="." \
          --recurse-submodules=":(exclude)sub0" \
          --recurse-submodules=":(exclude)sub2" \
          multisuper multisuper_clone

Это было бы клонировать и обновлять каждые подмодулях, кроме sub0 и sub2.

Бонус с Git 2.22 (Q2 2019) " git clone --recurs " работает лучше.

См. Коммит 5c38742 (29 апреля 2019 г.) Нгуен Тай pclouds Дуй (pclouds).
^{(Объединено Junio C Hamano - gitster - в коммите 2cfab60, 19 мая 2019 г.)}

parse-options: не выдавать "неоднозначную опцию" для псевдонимов

Измените механизм разбора параметров, чтобы, например, " clone --recurs... " не clone --recurs... ошибку, потому что " clone " понимает и " --recursive ", и " --recurse-submodules ", чтобы означать одно и то же.

Первоначально "клон" просто понимал --recursive до тех пор, пока --recurses-submodules был добавлен в ccdd3da (" clone: добавить --recurse-submodules качестве псевдонима для --recursive ", 2010-11-04, Git v1.7.4-RC0).
Поскольку bb62e0a (" clone: обучить --recurse-submodules при необходимости указывать путь", 2017-03-17, Git v2.13.0-rc0), более длинная форма была переведена в стандартную.

Но из-за того, как работает механизм разбора опций, это привело к довольно абсурдной ситуации:

$ git clone --recurs [...]
error: ambiguous option: recurs (could be --recursive or --recurse-submodules)

Добавьте OPT_ALIAS() чтобы выразить эту связь между двумя или более опциями и использовать ее в git-clone.