Если я изменяю подмодуль, могу ли я вернуть фиксацию в источник подмодуля, или для этого потребуется клон? Если клонировать, могу ли я сохранить клон в другом репозитории?
Если я изменяю подмодуль, могу ли я вернуть фиксацию в источник подмодуля, или для этого потребуется клон? Если клонировать, могу ли я сохранить клон в другом репозитории?
Ответы:
Подмодуль - это не что иное, как клон репозитория git в другом репо с некоторыми дополнительными метаданными (запись дерева gitlink, файл .gitmodules)
$ cd your_submodule
$ git checkout master
<hack,edit>
$ git commit -a -m "commit in submodule"
$ git push
$ cd ..
$ git add your_submodule
$ git commit -m "Updated submodule"
gh-pages
веткой документации по
Обратите внимание, что, поскольку в git1.7.11 ( [ANNOUNCE] Git 1.7.11.rc1 и примечание к выпуску , июнь 2012 г.) упоминается:
"
git push --recurse-submodules
" научился при желании просматривать истории субмодулей, связанных с суперпроектом, и выталкивать их.
Вероятно, будет сделано после этого патча и --on-demand
варианта:
recurse-submodules=<check|on-demand>::
Убедитесь, что все коммиты подмодулей, используемые отправляемыми ревизиями, доступны в ветке удаленного отслеживания.
- Если
check
используется, будет проверяться, что все коммиты подмодуля, которые были изменены в отправляемых ревизиях, доступны на удаленном компьютере.
В противном случае отправка будет прервана и завершится с ненулевым статусом.- Если
on-demand
используется, все подмодули, которые были изменены в отправляемых ревизиях, будут отправлены.
Если по запросу не удалось отправить все необходимые изменения, он также будет прерван и выйдет с ненулевым статусом.
Таким образом, вы можете нажать все за один раз с (из родительского репо):
git push --recurse-submodules=on-demand
Этот вариант работает только для одного уровня вложенности. Изменения субмодуля внутри другого субмодуля не будут перенесены.
С git 2.7 (январь 2016 г.) простого git push будет достаточно, чтобы протолкнуть родительский репо ... и все его подмодули.
См. Коммит d34141c , фиксацию f5c7cd9 (3 декабря 2015 г.), фиксацию f5c7cd9 (3 декабря 2015 г.) и фиксацию b33a15b (17 ноября 2015 г.) Майком Кроу ( mikecrowe
) .
(Объединено Junio C Hamano - gitster
- в коммите 5d35d72 , 21 декабря 2015 г.)
push
: добавитьrecurseSubmodules
параметр конфигурацииПараметр
--recurse-submodules
командной строки существует уже некоторое время, но не имеет эквивалента в файле конфигурации.Следуя стилю соответствующего параметра для
git fetch
, давайте придумаем,push.recurseSubmodules
чтобы задать для этого параметра значение по умолчанию.
Это также требует добавления,--recurse-submodules=no
чтобы разрешить переопределение конфигурации в командной строке при необходимости.Самый простой способ реализовать это, по-видимому, -
push
использовать кодsubmodule-config
аналогичноfetch
.
Теперь git config
документ включает :
push.recurseSubmodules
:Убедитесь, что все коммиты подмодулей, используемые отправляемыми ревизиями, доступны в ветви удаленного отслеживания.
- Если значение равно '
check
', то Git проверит, что все коммиты подмодуля, которые были изменены в отправляемых ревизиях, доступны по крайней мере на одном удаленном из подмодуля. Если какие-либо коммиты отсутствуют, push будет прерван и завершится с ненулевым статусом.- Если значение равно '
on-demand
', то все подмодули, которые изменились в ревизиях, которые нужно отправить, будут отправлены. Если по запросу не удалось отправить все необходимые изменения, он также будет прерван и выйдет с ненулевым статусом. -- Если значение равно '
no
', то поведение по умолчанию - игнорирование подмодулей при нажатии - сохраняется.Вы можете изменить эту конфигурацию во время отправки, указав "
--recurse-submodules=check|on-demand|no
".
Так:
git config push.recurseSubmodules on-demand
git push
Git 2.12 (первый квартал 2017 г.)
git push --dry-run --recurse-submodules=on-demand
действительно будет работать.
См. Commit 0301c82 , commit 1aa7365 (17 ноября 2016 г.) Брэндон Уильямс ( mbrandonw
) .
(Объединено Junio C Hamano - gitster
- в коммите 12cf113 , 16 декабря 2016 г.)
push run with --dry-run
на самом деле (Git 2.11, декабрь 2016 г. и ниже / ранее) не выполняет пробный запуск, если push настроен на отправку подмодулей по запросу.
Вместо этого все подмодули, которые необходимо протолкнуть, фактически подталкиваются к своим пультам, в то время как любые обновления для суперпроекта выполняются как пробный запуск.
Это ошибка, а не предполагаемое поведение при пробном запуске.Научите
push
уважать--dry-run
опцию при настройке на рекурсивную отправку подмодулей «по запросу».
Это делается путем передачи--dry-run
флага дочернему процессу, который выполняет push для подмодулей при выполнении пробного прогона.
И все же в Git 2.12 у вас теперь есть " --recurse-submodules=only
" возможность выталкивать подмодули, не выталкивая суперпроект верхнего уровня .
См. Commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 декабря 2016 г.) Брэндон Уильямс ( mbrandonw
) .
(Объединено Junio C Hamano - gitster
- в коммите 792e22e , 31 января 2017 г.)
git config push.recurseSubmodules on-demand
. Тогда простогоgit push
будет достаточно, чтобы все запихнуть (основное репо и подмодули). См. Мой отредактированный ответ ниже .