Что происходит при использовании git worktree с git подмодулями

Ответ 1

Совершенно ясно, что коммит a83a66a:

git-submodule.sh ожидает, что $GIT_DIR/config будет для каждого рабочего дерева, по крайней мере для submodule.* part.
Здесь я думаю, что у нас есть два варианта:

• либо обновите config.c чтобы он также читал $GIT_DIR/config.worktree (для каждого рабочего дерева) в дополнение к $GIT_DIR/config (shared), и сохраняйте переменные, специфичные для рабочего дерева, в новом месте,
• или обновите git-submodule.sh для чтения/записи submodule.* непосредственно из $GIT_DIR/config.submodule (для каждого рабочего дерева).

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

В целом, где разместить эти подмодули?

Есть пара вариантов:

• Вы можете захотеть хранить репозитории $SUB другом месте (возможно, в центральном месте) за пределами $SUPER. Это также верно для вложенных подмодулей, где суперпроект может быть подмодулем другого суперпроекта.
• Вы можете хранить все репозитории $SUB в $SUPER/modules (или в другом месте в $SUPER)
• Мы могли бы даже продвинуть его дальше и объединить все репозитории $SUB в $SUPER вместо того, чтобы хранить их отдельно. Но для этого, по крайней мере, потребуется включить пространство имен ref.

Этот коммит был ответом на коммит df56607.

С точки зрения пользователя git, это означает, что git submodule update --init --recursive не знает точно, где git submodule update --init --recursive подмодули.
Они дублируются на всех рабочих деревьях или они где-то централизованы? Это еще не указано формально.

Год спустя (и с git 2.9), Clacke добавляет в комментариях

путаница была решена, но не оптимальным образом.
Насколько я вижу, подмодули работают нормально, но у каждого рабочего дерева есть свой собственный набор репозиториев подмодулей (по motherrepo.git/worktree/<worktreename>/modules/<submodule>), поэтому, если у вас есть такой большой подмодуль, вы сталкиваются с серьезным использованием диска.

Git псевдонимы для обработки подмодулей в поддеревьях:

• https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L11
• https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L12

Псевдоним git wtas предполагает, что git wta определен глобально или, по крайней мере, для всех задействованных репо. Гарантия не включена. Ваш любимый питомец может заразиться болезненной инфекцией, если в ваших путевых именах есть пробелы.

Ожидается, что структура вашего репо будет такой же, как и в непроигрышном репо с инициированными подмодулями, поэтому, если у вас есть голое репо, вам придется подражать этой установке. Подмодуль с именем (не путем) foo в <your-.git-directory>/modules/foo (не .../foo.git). Он не вылетит, если какой-либо модуль отсутствует в репо, он просто пропустит его.

Есть возможности для улучшения. Он не обрабатывает подмодули внутри подмодулей, он опускается только на один уровень ниже. Это может сработать, чтобы просто изменить подмодуль git wta call на git wtas call, но я еще не проверял это.

- глухой

См. Также git worktree move (с Git 2. 17+, Q2 2018).

Фактически, до Git 2.21 (Q1 2019) " git worktree remove " и " git worktree move " отказывались работать, когда задействован субмодуль.
Это было ослаблено, чтобы игнорировать неинициализированные подмодули.

См. Коммит 00a6d4d (05 января 2019 г.) Нгуен Тай pclouds Дуй (pclouds).
^{(Объединено Junio C Hamano - gitster - в коммите 726f89c, 18 января 2019 г.)}

worktree: позволяет (пере) перемещать рабочие деревья с неинициализированными подмодулями

У неинициализированных подмодулей нет ничего ценного для нас. Они просто ША-1.
Пусть в этом случае " worktree remove " и " worktree move " продолжаются, чтобы люди могли по-прежнему использовать несколько рабочих деревьев в репозиториях с необязательными подмодулями, которые никогда не заполняются, например, sha1collisiondetection в git.git если он проверен сценарием doc-diff.

Обратите внимание, что для " worktree remove ", возможно, что пользователь инициализирует подмодуль (*), делает некоторые коммиты (но не push), а затем деинициализирует его.
На этом этапе подмодуль не заселен, но новые ценные коммиты все еще находятся в:

$GIT_COMMON_DIR/worktrees/<worktree>/modules/<submodule>

директории, и мы не должны разрешать удаление рабочего дерева, иначе мы потеряем эти коммиты навсегда.
Новая проверка каталога добавлена, чтобы предотвратить это.

(*) да, в любом случае, они все испортили, так как " git submodule " добавил бы submodule.* в $GIT_COMMON_DIR/config, который используется несколькими рабочими деревьями.
Но это не значит, что мы позволим им облажаться еще больше.