Обновите подмодуль Git до последней фиксации на источнике

Question

У меня есть проект с подмодулем Git.Он находится на URL-адресе ssh: // ... и находится в коммите A. Коммит B был отправлен на этот URL, и я хочу, чтобы субмодуль получил коммит и изменил его.

ТеперьНасколько я понимаю, git submodule update должен сделать это, но это не так.Он ничего не делает (нет вывода, код успешного завершения).Вот пример:

$ mkdir foo
$ cd foo
$ git init .
Initialized empty Git repository in /.../foo/.git/
$ git submodule add ssh://user@host/git/mod mod
Cloning into mod...
user@host's password: hunter2
remote: Counting objects: 131, done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 131 (delta 54), reused 0 (delta 0)
Receiving objects: 100% (131/131), 16.16 KiB, done.
Resolving deltas: 100% (54/54), done.
$ git commit -m "Hello world."
[master (root-commit) 565b235] Hello world.
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 mod
# At this point, ssh://user@host/git/mod changes; submodule needs to change too.
$ git submodule init
Submodule 'mod' (ssh://user@host/git/mod) registered for path 'mod'
$ git submodule update
$ git submodule sync
Synchronizing submodule url for 'mod'
$ git submodule update
$ man git-submodule 
$ git submodule update --rebase
$ git submodule update
$ echo $?
0
$ git status
# On branch master
nothing to commit (working directory clean)
$ git submodule update mod
$ ...

Я также попробовал git fetch mod, который, кажется, делает выборку (но не может, потому что не запрашивает пароль!), Но git log иgit show отрицать существование новых коммитов.До сих пор я только что rm -обработал модуль и заново его добавил, но на практике это неправильно и утомительно.

Answer 1

Вот потрясающая однострочная версия, чтобы обновить все до последней версии на мастере.

git submodule foreach 'git fetch origin --tags; git checkout master; git pull' && git pull && git submodule update --init --recursive

Спасибо Марку Джакиту

Answer 2

Обратите внимание, что современная форма обновления коммитов подмодулей будет выглядеть так:

git submodule update --recursive --remote --merge --force

Старая форма была:

git submodule foreach --quiet git pull --quiet origin

За исключением ... эта вторая форма не совсем "тихая".

См. коммит a282f5a (12 апреля 2019 г.) Нгуен Тай Нгёк Дуй (pclouds) .
^{(Объединено с Junio ​​C Hamano - gitster - in commit f1c9f6c , 25 апреля 2019 г.)}

submodule foreach: исправлена ​​ошибка "<command> --quiet"

Робин сообщил, что

git submodule foreach --quiet git pull --quiet origin

уже не совсем тихо.
Должно быть тихо до fc1b924 (submodule: порт submodule подкоманда 'foreach' от оболочки до C, 2018-05-10, Git v2.19.0-rc0), потому что parseopt может Не случайно есть варианты.

"git pull" ведет себя так, как будто --quiet не задано.

Это происходит потому, что parseopt в submodule--helper попытается разобрать оба варианта --quiet, как если бы они были параметрами foreach, а не git-pull.
Проанализированные параметры удаляются из командной строки. Итак, когда мы делаем потяните позже, мы выполним только это

git pull origin

При вызове помощника субмодуля добавление «--» перед «git pull» приведет к остановка parseopt для анализа параметров, которые на самом деле не принадлежат submodule--helper foreach.

PARSE_OPT_KEEP_UNKNOWN удаляется в качестве меры безопасности. parseopt следует никогда не вижу неизвестных вариантов или что-то пошло не так. Это также обновление строки использования пары, пока я смотрю на них.

Во время этого я также добавляю "--" к другим подкомандам, которые передают "$@" submodule--helper. «$@» в этих случаях являются путями и менее вероятны --something-like-this.
Но точка зрения остается в силе, git-submodule проанализировал и классифицировал, какие есть варианты, какие есть пути.
submodule--helper никогда не следует рассматривать пути, переданные git-submodule, как параметры, даже если они выглядят как один.

---

И Git 2.23 (Q3 2019) исправляет другую проблему: «git submodule foreach» не защищал параметры командной строки, передаваемые команде для правильного запуска в каждом подмодуле, когда использовалась опция «--recursive».

См. 30db18b (24 июня 2019 г.) Сонет Мориана (momoson) .
^{(Объединено с Junio ​​C Hamano - gitster - в коммит 968eecb , 09 июля 2019 г.)}

submodule foreach: исправление рекурсии опций

Призвание:

git submodule foreach --recursive <subcommand> --<option>

приводит к ошибке, утверждающей, что опция --<option> неизвестна submodule--helper.
Это, конечно, только тогда, когда <option> не является допустимым параметром для git submodule foreach.

Причина этого в том, что вышеуказанный вызов внутренне переводится в вызов субмодуля - помощника:

git submodule--helper foreach --recursive \
    -- <subcommand> --<option>

Этот вызов начинается с выполнения подкоманды с ее опцией внутри подмодуль первого уровня и продолжается, вызывая следующую итерацию submodule foreach вызов

git --super-prefix <submodulepath> submodule--helper \
   foreach --recursive <subcommand> --<option>

внутри подмодуля первого уровня. Обратите внимание, что двойная черта перед подкоманда отсутствует.

Эта проблема начинает возникать только недавно, поскольку флаг PARSE_OPT_KEEP_UNKNOWN для разбора аргумента git submodule foreach был убран в коммите a282f5a .
Следовательно, неизвестная опция теперь жаловалась, так как разбор аргументов не заканчивается должным образом двойной чертой.

Этот коммит устраняет проблему, добавляя двойную черту перед подкомандой во время рекурсии.