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

Ось частина вмісту мого .gitmodulesфайлу:

[submodule "src/static_management"]
        path = src/static_management
        url = git://github.com/eykd/django-static-management.git
[submodule "external/pyfacebook"]
        path = external/pyfacebook
        url = http://github.com/sciyoshi/pyfacebook.git

Однак .git/configмістить лише перше:

[submodule "src/static_management"]
        url = git://github.com/eykd/django-static-management.git

Другий підмодуль ( 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справді потрібне вручне втручання (додавання запису підмодуля вручну ), і чому?

Редагувати: ручне втручання не працює. Ручне додавання нового запису на підмодуль .git/configнічого не робить. Новий підмодуль ігнорується.

Ви нещодавно оновили до git версії 1.7.0.4? У мене були і зараз у мене є подібні проблеми ...

Редагувати: я вирішив свою проблему, але абсолютно не маю уявлення, де б це була проблема. Я вручну видалив записи підмодулю з обох .git / config та .gitmodules та повторно додав свої підмодулі з кроком використання ususa (git submodule add etc. ...). Працює, але не додає значення до цього потоку.

У мене була така ж проблема - виявилося, що файл .gitmodules був скоєний, але власне фіксований підмодуль (тобто запис ID комісії підмодуля) не був.

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

git submodule add http://github.com/sciyoshi/pyfacebook.git external/pyfacebook

(Навіть не виймаючи нічого з .git / config або .gitmodules.)

Потім виконайте це, щоб правильно записати ідентифікатор.

Додавання додаткових коментарів до цієї робочої відповіді: Якщо підмодуль git init або оновлення субмодуля git не працює, то, як описано вище, підмодуль git додає URL-адресу. Перевірити це можна за допомогою

 git config --list

і слід отримати запис підмодуля, який потрібно витягнути, в результаті команди git config --list. Якщо в результаті конфігурації є запис вашого підмодуля, то тепер звичайне оновлення підмодуля git --init повинне тягнути ваш підмодуль. Щоб перевірити цей крок, ви можете вручну перейменувати підмодуль та потім оновити його.

 mv yourmodulename yourmodulename-temp
 git submodule update --init

Щоб дізнатися, чи є у вас місцеві зміни в підмодулі, його можна побачити через статус git -u (якщо ви хочете побачити зміни в підмодулі) або статус git --ignore-підмодулі (якщо ви не хочете бачити зміни в підмодуль).

версія 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. зафіксувати і натиснути всі файли - .gitmodulesі папку вашого модуля (зауважте, що вміст папки не буде виконуватись)
5. киньте своє місцеве git repo
6. клон нового
7. переконайтесь, що .git/configще немає підмодулів
8. Тепер, git submodule init- і ви побачите повідомлення, які модуль зареєстрував
9. git submodule update - вийде модуль
10. Тепер подивіться, .git/configі ви знайдете зареєстрований підмодуль

Здається, тут багато (і) у відповідях багато плутанини.

git submodule initце НЕ призначене , щоб чарівним чином генерувати речі в .git / конфігурації (від .gitmodules). Він призначений створити щось у абсолютно порожньому підкаталозі після клонування батьківського проекту або витягнення комітету, який додає раніше неіснуючий підмодуль.

Іншими словами, ви слідуєте за git cloneпроектом, який містить підмодулі (про що ви дізнаєтесь, що клон перевірив файл .gitmodules) a git submodule update --init --recursive.

Ви НЕ слідувати git submodule add ...з git submodule init(або git submodule update --init), який не повинен працювати. Насправді додаток уже оновить відповідний .git / config, якщо все працює.

EDIT

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

У мене була така ж проблема, але жодне з вищезазначених рішень не допомогло. Записи в .gitmodules та в .git / config були правильними, але команда git submodules update --init --recursiveнічого не робила. Я також видалив каталог підмодулів і запустив git submodules update --init --recursiveі повернув каталог підмодулів назад, але з точно таким же посвідченням, як і раніше.

Я знайшов відповідь на цій сторінці . Команда така:git submodule update --remote

Начебто магічно, але сьогодні я побіг git submodule initза ним, git submodule syncа за git submodule updateним почали тягнути мої підмодулі ... Магія? Можливо! Це справді одне з найприємніших вражень від Git ...

Почешіть це. Я насправді працював цим git submodule update --init --recursive. Сподіваюся, це допомагає.

PS: Переконайтеся, що ви перебуваєте в кореневій директорії git, а не в підмодулі.

Думаючи, що налаштування вручну .gitmodulesдосить, це НЕПРАВНО

Мої місцеві git version 2.22.0станом на це написання.

Тому я підійшов до цієї теми, цікавившись, чому не git submodule initпрацює; Я налаштував .gitmodulesфайл і продовжував робити git submodule init...

ВАЖЛИВО

1. git submodule add company/project.git includes/projectце потрібно (при додаванні модуля в перший раз), це буде:

   • Додати конфігурацію в .git/config
   • оновити .gitmodulesфайл
   • відстежувати місце підмодуля ( includes/projectу цьому прикладі).

2. Ви повинні потім git commitпісля додавання підмодуля, це буде здійснювати .gitmodulesі гусеничне місце підмодуля.

Коли проект буде знову клонований, він матиме .gitmodulesі порожній каталог підмодулів (наприклад, includes/projectу цьому прикладі). На даний момент .git/configще немає конфігурації підмодулю, поки git submodule initне запущено, і пам'ятайте, що це працює лише тому, що .gitmodulesAND includes/projectвідслідковуються в основному git repo.

Також для ознайомлення див .:

• Як видалити підмодуль?
• Як перемістити існуючий підмодуль?

Відповідно до відповіді Дейва Джеймса Міллера, я можу підтвердити, що це працювало на мене. Важливим тут було присвоєння ідентифікаторів підпроектів. Просто для введення в .gitmodules було недостатньо.

Ось відповідна комісія:

https://github.com/dirkaholic/vagrant-php-dev-box/commit/d5f4c40bdbd80eefbb5ac6029823733f591435ae

У мене була така ж проблема.

.gitmodulesмав підмодуль, але після git submodule initкоманди його не було .git/config.

Виявляється розробник, який додав підмодуль, також додав каталог підмодулів у .gitignoreфайл. Це не працює.

Як і ви, я виявив, що синхронізація з підмодулем git не робить те, що ви очікуєте. Лише після явногоgit submodule add повторного повтору зміни URL-адреси підмодуля змінюється.

Отже, я вклав цей сценарій ~/bin/git-submodule-sync.rb :

https://gist.github.com/frimik/5125436

І я також використовую ту саму логіку у кількох сценаріях розгортання git після отримання.

Все, що мені потрібно зробити зараз - це редагувати .gitmodules, потім запустити цей сценарій, і він, нарешті, працює так, як я думав git submodule sync.

У мене була така ж проблема сьогодні, і я зрозумів, що тому що я набрав git submodule initтоді, у мене були такі рядки .git/config:

[submodule]
   active = .

Я видалив це і набрав:

git submodule update --init --remote

І все повернулося до норми, мій підмодуль оновлено у своєму підкаталозі, як завжди.

Проблема для мене полягає в тому, що попередній розробник repo створив submodules/thingпапку як звичайну папку, тобто коли я намагався запустити git submodule add ..., вона не вдасться:'submodules/thing' already exists in the index але спроба оновити підмодуль також буде невдалою, оскільки він побачив, що шлях не містять підмодуль.

Щоб виправити, мені довелося видалити submodules/thingпапку, здійснити видалення, а потім виконати git submodule addкоманду, щоб правильно її додати:

git submodule add --force --name thing https://github.com/person/thing.git submodules/thing

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

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

Видалення режиму субмодуля dir та його вмісту (папка "зовнішня / pyfacebook"), якщо вона існує раніше, git submodule add ...може усунути проблеми.

У мене була подібна проблема з підмодулем. Просто не хотілося клонувати / витягувати / оновлювати / що завгодно.

При спробі повторного додавання підмодулю за допомогою git submodule add git@my-repo.git destinationя отримав такий вихід:

A git directory for 'destination' is found locally with remote(s):
  origin        git@my-repo.git
If you want to reuse this local git directory instead of cloning again from
  git@my-repo.git
use the '--force' option. If the local git directory is not the correct repo
or you are unsure what this means choose another name with the '--name' option.

Отже, я спробував застосувати команду add :
git submodule add --force git@my-repo.git destination

Це спрацювало в моєму випадку.

Для запису:
я створив ту саму проблему, додавши порожній сховище як підмодуль. У цьому випадку для підмодулю не було довідкового хешу, що призводить до помилки, описаної оригінальним плакатом.

Примусове додавання сховища після його зобов'язання вирішило проблему (як у публікації Arvids)
git submodule add --force git@my-repo.git destination

• Видаліть підмодуль зі свого .git/config
• Виконати git submodule initкоманду
• Перейдіть до каталогу свого підмодуля та запустіть git pull origin master

Це має працювати зараз

Просто діліться тим, що працювало для мене:

git clone --recurse-submodules <repository path>

Це клонує віддалений сховище, що вже включає підмодулі. Це означає, що вам не потрібно буде запускати оновлення підмодуля git або init після клонування.

Нижче команда синхронізації вирішила проблему:

git submodule sync