Меню

Git submodule init не работает

Git Submodule иногда ломаются, как их починить?

Наверняка если вы начали читать эту статью, то знаете, что такое git и для чего он нужен. НО не все используют такую интересную функциональность в git как submodules.

Это дает возможность прицепить к вашему проекту другие проекты и переиспользовать их в вашем. Для примера рассмотрим такую историю.

Есть репозиторий, в котором содержится groovy скрипт, который решает задачу по извлечению из системы хранения чувствительных данных Vault.

Git репозиторий с Vault

Также есть репозиторий CICD, в которых содержатся конвейеры конкретных приложений.

Git репозиторий с submodules

Для того, чтобы подключить репозиторий Vault к репозиторию CICD как submulde необходимо выполнить, зафиксировать commit и отправить push в ветку dev

в итоге появляется файл .gitsubmodules и в нем соответствующая запись

Vault локально в Intellij Idea

Если кстати решите отключить submudule , то необходимо сделать следующее

и удаляем из .gitmodules секцию [submodule «vault»]

Если вы что-то поменяли в репозитории Vault и хотите чтобы указатель в основном проекте был перемещен на самый новый коммит и изменения были отправлены в ветку master необходимо сделать следующее:

Чаше всего все работает штатно, но иногда обстоятельства складываются таким образом:

22:00 пятница и вы хотите получить именно сегодня результат, потому как потратили на этот pipeline почти целый день, просто уйти и бросить задачу — вы не только не получите свою дозу дофамина, а у вас еще выработается дополнительная доза кортизола,

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

на 25 минуте у вас получилось наконец-то полностью доделать pipeline и протестировать deployment.yml и теперь осталось дело за малым раскомментировать stage с build и протестировать снова и в процессе внести косметическое изменение в проект в vault, вы нормально коммитите в соответствующие репозитории и на основном проекте выполняете

но что-то идет не так и когда вы запускаете Job в Jenkins возвращается ошибка

пробуете перейти в giltab по ссылке vaurt @ то вам возвращается 404 ошибка

404 ошибка при попытке перехода на git submodule vault

Для примера нашел подобные ошибки на toster.ru

https://qna.habr.com/q/131671

В ответе было написано что гуглится 10 секунд, но четкого скрипта как восстановить работоспособность найдено не было и я решил что моя история как это быстро починить репозиторий CICD будет полезна

Начинаем с клонировая репозитория

далее необходимо сделать инициализацию submodule

далее выполняем рекурсивный update

далее пробуем выполнить update именно sub модуля vault

получаем в ответ ошибку

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

ветка верная v1

далее выполняем актуализацию

мы обновили каталог с sub modules до последнего коммита repo с vault, теперь необходимо перейти в каталог с основным проектом и сохранить изменения

далее зафиксированные изменения мы отправляем в репозиторий с проектом

проверяем repo с проектом, что все сработало как нужно

commit Fix old commit with vault

переходим по ссылке после @

восстановленная ссылка git submodule на репозиторий с Vault

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

Источник

git submodule init does absolutely nothing

I have a strange problem with «git submodule init»

When I added the submodules using «git submodule add url location» it cloned the repository just fine and everything was ok.

When I pushed all my changes back to the parent repository, added the .gitmodules files, etc and cloned the repository back, I tried to initialise all the submodules using «git submodule init»

And nothing happens 🙁 Literally nothing, no output, no extra files, it does not even attempt to do anything actually.

Читайте также:  Как настроить цифровые каналы через wifi

So I am wondering, what did I do wrong?

3 Answers 3

ok, I have figured out what I did wrong.

When I added the git submodules, I did a git status and it told me three things had changed

when I was pushing all my changes to the repository, I didnt want to commit the submodules, cause I thought it would add all the files I just cloned, so I just did a git add .gitmodules and committed and pushed that.

But this is wrong, you need to do a git commit and commit everything it tells you, then when you do this, git registers those paths and when you clone, it will work.

but if you do not commit those folders, it wont register them and wont clone them when you clone the parent repository.

so that was my mistake, I misunderstood that adding those directories would add all the submodules code to the parent repository, I tried to sidestep that and it stopped working.

so just add your submodules and commit the results, it will all work out just fine 😀

Источник

Git не будет инициализировать / синхронизировать / обновлять новые подмодули

вот часть содержимого моего :

, .git/config содержит только первый:

второй подмодуль ( external/pyfacebook ) был добавлен другим разработчиком в отдельную ветку. Теперь я унаследовал разработку и проверил ветку функций. Однако Git не будет тянуть подмодуль для меня. Я попробовал:

  • git submodule init
  • git submodule update
  • git submodule update —init
  • git submodule sync
  • удаление всех определений подмодулей из .git/config и под управлением git submodule init . Он копирует только ранее существующий подмодуль и игнорирует новый.
  • ввод новых определений подмодулей в .git/config вручную и работает git submodule update . Только ранее существующие подмодули утруждают себя обновлением.

в различных комбинаций, но git просто не будет обновлять .git/config на основе нового содержания .gitmodules , и он не создаст external/pyfacebook папка и вытащить содержимое подмодуля.

что я упустил? Является ручным вмешательством (добавление записи подмодуля вручную в .git/config ) действительно требуется, и почему?

Edit: ручное вмешательство не работает. Вручную добавление новой записи подмодуля в .git/config ничего не делает. Новый подмодуль игнорируется.

14 ответов

вы недавно обновились до git версии 1.7.0.4 ? У меня были и сейчас возникают аналогичные проблемы.

Edit:я исправил свою проблему, но абсолютно не знаю, где проблема была. Я вручную удалил записи подмодуля из обоих .в git/config и .gitmodules и re-added мои подмодули с ususal шагами (git submodule add etc. ) . Worksforme, но не добавляет значения в этот поток.

у меня была эта же проблема — оказалось, что .файл gitmodules был зафиксирован, но фактическая фиксация подмодуля (т. е. запись идентификатора фиксации подмодуля) не была.

добавление его вручную, казалось, сделало трюк-например:

(даже не вынимая ничего из .в git/config или .gitmodules.)

затем зафиксируйте его для правильной записи идентификатора.

добавление дополнительных комментариев к этому рабочему ответу: если подмодуль git init или обновление подмодуля git не работает, а затем, как описано выше, git submodule add url должен сделать трюк. Можно проверить это с помощью

и нужно получить запись подмодуля, который вы хотите вытащить в результате команды git config —list. Если в результате конфигурации есть запись вашего подмодуля, то теперь обычное обновление подмодуля git —init должно вытащить ваш подмодуль. Чтобы проверить этот шаг, можно вручную переименовать подмодуль, а затем обновить подмодуль.

чтобы узнать, есть ли у вас локальные изменения в подмодуле, его можно увидеть через git status-u ( если вы хотите увидеть изменения в подмодуле ) или git status —ignore-submodules ( если вы не хотите видеть изменения в подмодуле ).

git версии 2.7.4. Эта команда обновляет локальный код git submodule update —init —force —remote

была такая же проблема, когда git игнорировал init и update команды, и ничего не делает.

Читайте также:  Как настроить двухфакторную защиту инстаграм

КАК ИСПРАВИТЬ

  1. ваша папка подмодуля должна быть зафиксирована в Git repo
  2. его не должно быть .gitignore

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

если вы сделали все это, и это все еще не работа:

  1. добавить подмодуль вручную, например git submodule add git@. path/to
  2. git submodule init
  3. git submodule update
  4. commit и push все файлы — .gitmodules и папку вашего модуля (обратите внимание, что содержимое папки не будет фиксироваться)
  5. отбросьте местное РЕПО git
  6. клонировать новый
  7. обеспечить .git/config еще нет никаких подмодулей
  8. теперь git submodule init — и вы увидите сообщение, что модуль зарегистрирован
  9. git submodule update — достану модуль
  10. теперь посмотрим на .git/config и вы найдете зарегистрированный подмодуль

вроде волшебно, но сегодня я побежал git submodule init затем git submodule sync затем git submodule update и он начал вытаскиваю свои подмодули. Магия? Возможно! Это действительно один из самых раздражающие впечатления от Git.

нуля, что. Я на самом деле получил его работу, делая git submodule update —init —recursive . Надеюсь, это поможет.

PS: убедитесь, что вы находитесь в корневом каталоге git, а не в подмодуле.

кажется, здесь много путаницы (также) в ответах.

git submodule init is не предназначен для магического создания материала .git / config (from .gitmodules). Он предназначен для настройки чего-то в совершенно пустом подкаталоге после клонирования родительского проекта или извлечения фиксации, которая добавляет ранее несуществующий подмодуль.

другими словами, вы следуете git clone проекта, который имеет подмодули (которые вы узнаете по тому, что клон проверил а .gitmodules файл) с помощью git submodule update —init —recursive .

ты не соблюдать git submodule add . С git submodule init (или git submodule update —init ), что не должно работать. Фактически, add уже обновит соответствующий .в git/config, если все работает.

редактировать

если ранее несуществующий подмодуль git был добавлен кем-то другим, и вы делаете git pull этой фиксации, то каталог этого подмодуля будет полностью пустым (когда вы выполняете git submodule status хэш нового подмодуля должен быть видимым, но будет иметь — перед ним.) В этом случае вам нужно следовать вашему git pull и git submodule update —init (плюс —recursive когда это подмодуль внутри подмодуля), чтобы получить новый, ранее несуществующий подмодуль; так же, как после первоначального клона проекта с подмодулями (где, очевидно, у вас не было этих подмодулей раньше).

согласно ответу от Дэйва Джеймса Миллера, я могу подтвердить, что это сработало для меня. Здесь важно было зафиксировать идентификатор фиксации подпроектов. Просто чтобы иметь вход .gitmodules было недостаточно.

вот соответствующая фиксация:

у меня была та же проблема.

.gitmodules имел подмодуль, но после git submodule init команда это не было в .git/config .

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

так же, как и вы, я обнаружил, что git submodule sync не делает того, что вы ожидаете. Только после выполнения явного git submodule add снова изменяет url подмодуля.

Итак, я поместил этот сценарий в

и я также использую ту же логику для нескольких сценариев развертывания git после получения.

все, что мне нужно сделать сейчас, это изменить .gitmodules , затем запустите этот скрипт, и он, наконец, работает, как я думал git submodule sync предполагалось.

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

добавление подмодулей обратно и сравнение shas фиксации подмодуля с найденными в git show $breaking_commit_sha (поиск строк, соответствующих регулярному выражению ^-Subproject ), чтобы настроить по мере необходимости фиксированные вещи.

Читайте также:  Как настроить панель инструментов ворде

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

при попытке повторно добавить подмодуль с помощью git submodule add git@my-repo.git destination Я получил следующий вывод:

Итак, я попытался применить команду «добавить»:
git submodule add —force git@my-repo.git destination

это сработало в моем случае.

у меня была та же проблема сегодня и понял, что так как я набрал git submodule init тогда у меня была эта строка в моем .git/config :

Я удалил это и набрал:

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

удаление подмодуля dir и его содержимого (папка» external/pyfacebook»), если он существует до git submodule add . может исправить проблемы.

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

Источник

git submodule update not functioning

I have a repository with various nested submodules. Committing and pushing works pretty well and the changes are visible at GitHub as expected.

In the testing/production environments, new releases of this project are being deployed using these commands:

But this only updates the root project, none of the submodules are updated to the commits associated with the HEAD at GitHub. So far the only way I have found to update the whole project is to run git pull inside each individual submodule folder.

I understand that git submodule update is the method referenced in most places, but it is not really producing any results in this case. What could be the cause?

2 Answers 2

You need to make sure your submodules are following a branch, or they will only be checked out at a specific SHA1 (not at the latest of a branch, but the special entry of the index of your parent repo)

See «Git submodules: Specify a branch/tag» in order to make your submodule follow a branch.

Then a git submodule update —init —recursive —remote would be enough to check out the latest from that branch.

This ( git submodule update —remote ) requires git 1.8.2+ March 2013. The OP Luís de Sousa has a git 1.7.9.5 (March 2012) which doesn’t offer this feature.

You have a specific version committed to your repository. For git the submodules are «files» containing a sha1-hash of the version you provided. git submodule update —init —recursive ensures that your submodule is available in exactly that version.

  • You make a git init on a directory and have a empty repo
  • You add a submodule using git submodule add which will record the current masters sha1-hash of that repo you are adding in your own repository
  • Multiple commits are made to the submodule but your repo will still contain that one hash you had as you added the submodule
  • If you make a git pull in the submodule you will get the new commits and have an uncommitted change in your own repository (the new sha1-hash of the submodules master)
  • As soon as you commit that change you are «pinning» the current version of the submodule
  • git submodule update will now enforce the new version is there

So if some other contributor of your own repository updates his checkout and does a git submodule update he will get the version you pinned. So in general the submodule update will do some work only when the submodule is not checked out or if someone changed the associated hash in your repository.

Источник

Adblock
detector