С git1.8.3 (22 апреля 2013 г.) :
Не было никакого Фарфорового способа сказать «Я больше не заинтересован в этом подмодуле», когда вы выразили свою заинтересованность в подмодуле с помощью «submodule init».
«submodule deinit» - это способ сделать это.
В процессе удаления также используется git rm (начиная с git1.8.5 октябрь 2013 г.).
Резюме
Трехэтапный процесс удаления будет:
0. mv a/submodule a/submodule_tmp
1. git submodule deinit -f -- a/submodule
2. rm -rf .git/modules/a/submodule
3. git rm -f a/submodule
# Note: a/submodule (no trailing slash)
# or, if you want to leave it in your working tree and have done step 0
3. git rm --cached a/submodule
3bis mv a/submodule_tmp a/submodule
Объяснение
rm -rf: Это упоминается в Даниэль Шредер ответ , и суммируется Eonil в комментариях :
Это оставляет .git/modules/<path-to-submodule>/ без изменений.
Поэтому, если вы однажды удалите подмодуль этим методом и снова добавите их, это будет невозможно, поскольку хранилище уже повреждено.
git rm: см. коммит 95c16418 :
В настоящее время использование «git rm» в подмодуле удаляет рабочее дерево подмодуля из суперпроекта и gitlink из индекса.
Но раздел подмодуля в .gitmodules остался нетронутым, что является остатком теперь удаленного подмодуля и может раздражать пользователей (в отличие от параметра в .git/config, это должно напоминать, что пользователь проявил интерес к этому подмодулю поэтому он будет заполнен позже, когда будет извлечен более старый коммит).
Позвольте «git rm» помочь пользователю, не только удаляя подмодуль из рабочего дерева, но также удаляя раздел «submodule.<submodule name>» из файла .gitmodules и ставя оба.
git submodule deinit: Происходит от этого патча :
С помощью "git submodule init" пользователь может сказать git, что он заботится об одном или нескольких подмодулях, и хочет, чтобы он был заполнен при следующем вызове "git submodule update".
Но в настоящее время нет простого способа сообщить git, что они больше не заботятся о подмодуле и хотят избавиться от локального рабочего дерева (если пользователь не знает много о внутренностях подмодуля и не удаляет настройку "submodule.$name.url" из .git/config вместе с самим рабочим деревом).
Помогите этим пользователям, введя команду deinit.
Этот удаляет весь submodule.<name> раздел из .git/config либо для заданного
субмодуль (ы) (или для всех тех, которые были инициализированы, если задано '.').
Ошибка, если текущее рабочее дерево содержит модификации, если не принудительно.
Пожаловаться, когда для подмодуля, заданного в командной строке, настройка URL не может быть найдена в .git/config, но, тем не менее, не происходит сбой.
Это заботится, если (де) шаги инициализации (.git/config и .git/modules/xxx)
Начиная с git1.8.5, git rm принимает , а также заботится о:
- '
add' шаг, который записывает URL подмодуля в файл .gitmodules: его нужно удалить за вас.
- подмодуль специальная запись (как показано этим вопросом ): git rm удаляет его из индекса:
git rm --cached path_to_submodule (без косой черты)
Это удалит этот каталог, сохраненный в индексе в специальном режиме «160000», пометив его как корневой каталог подмодуля.
Если вы забудете этот последний шаг и попытаетесь добавить субмодуль в качестве обычного каталога, вы получите сообщение об ошибке, например:
git add mysubmodule/file.txt
Path 'mysubmodule/file.txt' is in submodule 'mysubmodule'
Примечание: начиная с Git 2.17 (Q2 2018), подмодуль git deinit больше не является сценарием оболочки.
Это вызов функции C.
См. коммит 2e61273 , коммит 1342476 (14 января 2018) Пратамеш Чаван (pratham-pc) .
(Объединено с Junio C Hamano - gitster - в commit ead8dbe , 13 февраля 2018 г.)
git ${wt_prefix:+-C "$wt_prefix"} submodule--helper deinit \
${GIT_QUIET:+--quiet} \
${prefix:+--prefix "$prefix"} \
${force:+--force} \
${deinit_all:+--all} "$@"