Невозможно проверить путь к подмодулю git

У меня проблема при работе с подмодулями git.

Всякий раз, когда я получаю новую ссылку подмодуля из восходящего репозитория, выполнение git submodule update дает следующий результат:

fatal: reference is not a tree: dd208d46ecdd1ac0d2b2594a610fe4c9150fece1
Unable to checkout 'dd208d46ecdd1ac0d2b2594a610fe4c9150fece1' in submodule path 'submodule/path'

Важно отметить, что подмодуль имеет несколько пультов, из которых верхний пульт дистанционного управления должен использоваться для обновления дерева ссылок подмодуля. Я предполагаю, что моя проблема есть, но я не уверен.

Моя настройка такова:

Git проект

ПУлЬТОВ:

  • origin (my git fork)
  • upstream (project repo)

Модуль "Submodule", имеет пульты:

  • origin (my git fork)
  • upstream (project repo)

Кто-нибудь знает, что вызывает мою проблему?

Ответы

Ответ 1

При выполнении git submodule update, git пытается проверить сборку/дерево, которое сохраняется в суперпроекте (в вашем примере, с идентификатором commit dd208d4...)

Я думаю, вы получите ошибку, потому что внутри подмодуля нет такого объекта. Вы должны убедиться, что он есть. Обычно это означает, что вам нужно сначала извлечь/вытащить его с удаленного устройства.

Возможно, вам нужно

git submodule foreach git fetch
git submodule update

или, возможно,

git fetch --recurse-submodules

Предполагая, что подмодуль настроен, чтобы он мог получить отсутствующую фиксацию с удаленного origin. В конце концов, вы должны знать, откуда вы можете получить отсутствующую фиксацию, и вы должны ее получить.

Вы можете проверить, есть ли у вас dd208d4..., делая что-то вроде:

cd ./module
git log dd208d46ecdd1ac0d2b2594a610fe4c9150fece1
git cat-file -p dd208d46ecdd1ac0d2b2594a610fe4c9150fece1
git ls-tree dd208d46ecdd1ac0d2b2594a610fe4c9150fece1

Одной из возможных причин такой проблемы является то, что тот, кто опубликовал новую фиксацию из супермодуля, не опубликовал необходимые коммиты из подмодуля. Сначала он должен публиковать коммиты из подмодуля.

Ответ 2

Убедитесь, что субмодули были сдвинуты

cd submodule-dir
git push

В моем случае у меня было:

  • совершено в субмодуле
  • не толкнул
  • передано родителю с обновленными подмодулями
  • толкнул родителя

поэтому неудивительно, что его не удалось найти.

Далее можно автоматизировать толчки с помощью:

git push --recurse-submodules=on-demand

который также выдвигает субмодули по мере необходимости или начиная с 2.7:

git config push.recurseSubmodules on-demand
git push

Ответ 3

У меня была такая же проблема, и я решил добавить новую фиксацию для родительского проекта и нажать все Check the Subproject commit and commit from your module

Ответ 4

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

убедитесь, что изменения нажаты

Ответ 5

Моя проблема в том, что при cat .gitmodules моего репо я указывал на неправильный пульт для репозитория подмодуля (я изначально клонировал его с помощью оригинального пульта, но затем переключился на его вилку, gitmodules файл не обновляется, чтобы отразить изменение).

Ответ 6

Моя проблема заключалась в том, что у меня были незафиксированные изменения в подмодулях в файлах build.gradle(которые, я думаю, были автоматически изменены). Они появились в git diff. Я просто выполнил git checkout . до reset, когда репозитории подмодулей не имели никаких изменений, а затем работал git submodule update.

Ответ 7

Другой способ может быть, без параметров командной строки git, но сделать это вручную. Сценарий в основном происходит, когда пути подмодулей были перемещены/заменены (но не должным образом), тем самым по-прежнему указывая на старые ссылки в локальных хранилищах проверки.

1) Найдите хранилище и субмодуль

ls -la .git/modules
   rm -f .git/modules/<module-with-issue>

2) Удалить старые локальные конфигурации субмодулей

 gedit .git/config

(удалите запись субмодуля здесь)

Это выглядит примерно так;

 *[submodule "module-with-issue"]
       url = ...*

3) Теперь загрузите и обновите подмодули свежим обновлением git fetch git submodule --recursive --init

Примечание. Перед попыткой обновления субмодуля может потребоваться удалить локально извлеченную папку субмодуля в вашем хранилище.