Поскольку git1.8.3 ( 22 апреля 2013 г.):

Не было способа Porcelain сказать, что меня больше не интересует этот подмодуль, если вы выразите свой интерес к подмодулю с помощью git submodule init.
git 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: это упоминается в Daniel Schroeder answer и резюмированы Eonil в комментарии:

Это оставляет .git/modules/<path-to-submodule>/ без изменений.
Поэтому, если вы однажды удалите подмодуль этим методом и снова добавите его, это будет невозможно, потому что репозиторий уже поврежден.

git rm: См. совершить 95c16418:

В настоящее время использование git rm в подмодуле удаляет дерево работы подмодуля из дерева суперпроекта и gitlink из индекса.
Но раздел подмодуля в .gitmodules остается нетронутым, который является остатком от теперь удаленного подмодуля и может раздражать пользователей (в отличие от настройки в .git/config, это должно оставаться напоминанием о том, что пользователь проявил интерес к этому подмодулю, поэтому он будет повторно заполнен позже, когда будет извлечена более старая фиксация).

Пусть git rm поможет пользователю, не только удалив подмодуль из рабочего дерева, но также удалив раздел submodule.<submodule name> из файла .gitmodules и подготовив и то, и другое.

git submodule deinit: Это происходит из этого патча :

• Шаг «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 (второй квартал 2018 г.), подмодуль git deinit больше не является сценарием оболочки.
Это вызов функции C.

См. фиксацию 2e61273, commit 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} "$@"

На странице Учебник по подмодулю Git:

Чтобы удалить подмодуль, вам необходимо:

1. Удалите соответствующий раздел из файла .gitmodules.
2. Выполните .gitmodules изменения:
   git add .gitmodules
3. Удалите соответствующий раздел из .git/config.
4. Удалите файлы подмодулей из рабочего дерева и проиндексируйте:
   git rm --cached path_to_submodule (без косой черты в конце).
5. Удалите каталог .git подмодуля:
   rm -rf .git/modules/path_to_submodule
6. Подтвердите изменения:
   git commit -m "Removed submodule <name>"
7. Удалите файлы подмодуля, которые сейчас не отслеживаются:
   rm -rf path_to_submodule

См. также: альтернативные шаги ниже.

Большинство ответов на этот вопрос устарели, неполны или излишне сложны.

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

# Remove the submodule entry from .git/config
git submodule deinit -f path/to/submodule

# Remove the submodule directory from the superproject's .git/modules directory
rm -rf .git/modules/path/to/submodule

# Remove the entry in .gitmodules and remove the submodule directory located at path/to/submodule
git rm -f path/to/submodule

Просто примечание. Начиная с git 1.8.5.2, будут работать две команды:

git rm -r the_submodule
rm -rf .git/modules/the_submodule

Как правильно указал ответ @Mark Cheverton, если вторая строка не используется, даже если вы удалили подмодуль на данный момент, папка remnant .git / modules / the_submodule предотвратит добавление или замену того же подмодуля в будущем . Кроме того, как упоминал @VonC, git rm будет выполнять большую часть работы над подмодулем.

--Обновление (05.07.2017) -

Чтобы уточнить, the_submodule - это относительный путь подмодуля внутри проекта. Например, это subdir/my_submodule, если подмодуль находится внутри подкаталога subdir.

Как правильно указано в комментариях и других ответах, две команды (хотя функционально достаточны для удаления подмодуля) оставляют след в разделе [submodule "the_submodule"] документа .git/config (по состоянию на июль 2017 г.), который можно удалить с помощью третьей команды:

git config -f .git/config --remove-section submodule.the_submodule 2> /dev/null

Простые шаги

1. Удалить записи конфигурации:
   git config -f .git/config --remove-section submodule.$submodulename
git config -f .gitmodules --remove-section submodule.$submodulename
2. Удалить каталог из индекса:
   git rm --cached $submodulepath
3. Совершить
4. Удалите неиспользуемые файлы:
   rm -rf $submodulepath
rm -rf .git/modules/$submodulename

Обратите внимание: $submodulepath не содержит косых черт в начале и в конце.

Фон

Когда вы делаете git submodule add, он только добавляет его в .gitmodules, но как только вы сделали git submodule init, он добавлялся в .git/config.

Поэтому, если вы хотите удалить модули, но можете быстро восстановить их, сделайте следующее:

git rm --cached $submodulepath
git config -f .git/config --remove-section submodule.$submodulepath

Если вы поместите это в сценарий, рекомендуется сделать сначала git rebase HEAD, а в конце git commit.

Также ознакомьтесь с ответом на Могу ли я очистить подмодуль Git?.

В дополнение к рекомендациям мне также пришлось rm -Rf .git/modules/path/to/submodule, чтобы иметь возможность добавить новый подмодуль с тем же именем (в моем случае я заменял вилку оригинальной)

Чтобы удалить добавленный подмодуль, используйте:

git submodule add [email protected]:repos/blah.git lib/blah

Запустить:

git rm lib/blah

Вот и все.

Для старых версий git (около ~ 1.8.5) используйте:

git submodule deinit lib/blah
git rm lib/blah
git config -f .gitmodules --remove-section submodule.lib/blah

Вы должны удалить записи в .gitmodules и .git/config, а также удалить каталог модуля из истории:

git rm --cached path/to/submodule

Если вы напишете в список рассылки git, возможно, кто-нибудь напишет для вас сценарий оболочки.

Подводя итог, вот что вам следует сделать:

1. Установите path_to_submodule var (без косой черты в конце):

   path_to_submodule=path/to/submodule

2. Удалите соответствующую строку из файла .gitmodules:

   git config -f .gitmodules --remove-section submodule.$path_to_submodule

3. Удалите соответствующий раздел из .git / config

   git config -f .git/config --remove-section submodule.$path_to_submodule

4. Деактивировать и удалить $ path_to_submodule только из индекса (для предотвращения потери информации)

   git rm --cached $path_to_submodule

5. Отслеживайте изменения, внесенные в .gitmodules

   git add .gitmodules

6. Зафиксируйте суперпроект

   git commit -m "Remove submodule submodule_name"

7. Удалите теперь неотслеживаемые файлы подмодулей

   rm -rf $path_to_submodule

   rm -rf .git/modules/$path_to_submodule

Вы можете использовать псевдоним для автоматизации решений, предоставляемых другими:

[alias]
  rms = "!f(){ git rm --cached \"$1\";rm -r \"$1\";git config -f .gitmodules --remove-section \"submodule.$1\";git config -f .git/config --remove-section \"submodule.$1\";git add .gitmodules; }; f"

Поместите это в свою конфигурацию git, и тогда вы можете сделать: git rms path/to/submodule

Если подмодуль был добавлен случайно из-за того, что вы добавили, зафиксировали и отправили папку, которая уже была репозиторием Git (содержащая .git), у вас не будет файла .gitmodules для редактирования или чего-либо еще в .git/config. В этом случае все, что вам нужно, это:

git rm --cached subfolder
git add subfolder
git commit -m "Enter message here"
git push

FWIW, я также удалил папку .git перед выполнением git add.

Я обнаружил, что deinit мне подходит:

git submodule deinit <submodule-name>    
git rm <submodule-name>

Из git docs:

deinit

Отмените регистрацию данных подмодулей, т.е. удалите весь раздел submodule.$name из .git / config вместе с их рабочим деревом.

Поэкспериментировав со всеми разными ответами на этом сайте, я пришел к следующему решению:

#!/bin/sh
path="$1"
if [ ! -f "$path/.git" ]; then
  echo "$path is no valid git submodule"
  exit 1
fi
git submodule deinit -f $path &&
git rm --cached $path &&
rm -rf .git/modules/$path &&
rm -rf $path &&
git reset HEAD .gitmodules &&
git config -f .gitmodules --remove-section submodule.$path

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

git submodule add $giturl test
aboveScript test

Это оставляет вас с чистой проверкой без каких-либо изменений для фиксации.

Это было проверено с помощью:

$ git --version
git version 1.9.3 (Apple Git-50)

Чем я сейчас занимаюсь, декабрь 2012 г. (объединяет большинство из этих ответов):

oldPath="vendor/example"
git config -f .git/config --remove-section "submodule.${oldPath}"
git config -f .gitmodules --remove-section "submodule.${oldPath}"
git rm --cached "${oldPath}"
rm -rf "${oldPath}"              ## remove src (optional)
rm -rf ".git/modules/${oldPath}" ## cleanup gitdir (optional housekeeping)
git add .gitmodules
git commit -m "Removed ${oldPath}"

Вот что я сделал:

1.) Удалите соответствующий раздел из файла .gitmodules. Вы можете использовать команду ниже:

git config -f .gitmodules --remove-section "submodule.submodule_name"

2.) Выполните .gitmodules изменения

git add .gitmodules

3.) Удалить соответствующий раздел из .git/config. Вы можете использовать команду ниже:

git submodule deinit -f "submodule_name"

4.) Удалите gitlink (без косой черты):

git rm --cached path_to_submodule

5.) Очистите .git/modules:

rm -rf .git/modules/path_to_submodule

6.) Зафиксировать:

git commit -m "Removed submodule <name>"

7.) Удалите теперь неотслеживаемые файлы подмодулей.

rm -rf path_to_submodule

1. git submodule deinit <path to submodule>
2. Удалить раздел из .gitmodules
3. Звоните: git rm <path to submodule>
4. Удалите файлы модуля, которые нужно удалить из вашего проекта.
5. Добавьте удаленные файлы в git и вызовите git add .gitmodules
6. Зафиксировать и нажать

Недавно я обнаружил проект git, который включает множество полезных команд, связанных с git: https://github.com/visionmedia/git-extras

Установите его и введите:

git-delete-submodule submodule

Тогда дело сделано. Каталог подмодуля будет удален из вашего репо и все еще будет существовать в вашей файловой системе. Затем вы можете зафиксировать изменение, например: git commit -am "Remove the submodule".

Мне пришлось сделать шаги Джона Даутата еще на один шаг и cd в каталог подмодуля, а затем удалить репозиторий Git:

cd submodule
rm -fr .git

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

Вот 4 шага, которые я нашел необходимыми или полезными (в первую очередь важные):

git rm -f the_submodule
rm -rf .git/modules/the_submodule
git config -f .git/config --remove-section submodule.the_submodule
git commit -m "..."

Теоретически git rm на шаге 1 должен позаботиться об этом. Надеюсь, что на вторую часть вопроса OP однажды можно будет ответить положительно (что это можно сделать с помощью одной команды).

Но с июля 2017 г. необходим шаг 2 для удаления данных в .git/modules/, иначе вы не сможете, например, добавить подмодуль в будущем.

Вероятно, вы можете обойтись без двух вышеуказанных шагов для git 1.8.5+, как указано в ответе tinlyx, поскольку все команды git submodule кажутся работать.

Шаг 3 удаляет раздел для the_submodule в файле .git/config. Это нужно сделать для полноты картины. (Эта запись может вызвать проблемы для более старых версий git, но у меня нет ее для тестирования).

Для этого в большинстве ответов предлагается использовать git submodule deinit. Мне кажется более явным и менее запутанным использование git config -f .git/config --remove-section. Согласно документации git-submodule, git deinit:

Отмените регистрацию данных подмодулей ... Если вы действительно хотите удалить подмодуль из репозитория и зафиксировать, используйте вместо этого git-rm [1] .

И последнее, но не менее важное: если вы не git commit, вы получите / можете получить ошибку при выполнении git submodule summary (начиная с git 2.7):

fatal: Not a git repository: 'the_submodule/.git'
* the_submodule 73f0d1d...0000000:

Это независимо от того, выполняете ли вы шаги 2 или 3.

Я только что нашел скрытый файл .submodule (забыл точное имя), у него есть список ... вы можете стереть их индивидуально таким образом. У меня был только один, поэтому я удалил его. Просто, но это может испортить Git, так как я не знаю, прикреплено ли что-нибудь к подмодулю. Пока что вроде нормально, если не считать обычной проблемы с обновлением libetpan, но это (надеюсь) не связано.

Заметил, что никто не опубликовал ручное стирание, поэтому добавил

С git 2.17 и выше это просто:

git submodule deinit -f {module_name}
git add {module_name}
git commit

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

submodule="path/to/sub"              # no trailing slash!
git submodule deinit -- "$submodule"
git rm -- "$submodule"

• Если это не сработает, см. Ниже.
• Без вариантов. Ничего опасного. И даже не думайте делать больше!
• Протестировано с Debian Buster 2.20.1 и Ubuntu 18.04 2.17.1.
• "$submodule" просто чтобы подчеркнуть, где поставить имя, и что вы должны быть осторожны с пробелами и т.п.
• Если в Windows проигнорируйте первую строку и замените "$submodule" на путь Windows правильно указанного пути к подмодулю. (Я не винда)

Предупреждение!

Никогда не прикасайтесь к внутренностям .git каталога сами! Редактирование внутри .git ведет к темной стороне. Держитесь подальше любой ценой!

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

Я думаю, что в документации на git submodule есть очень опасная часть. Рекомендует удалить $GIT_DIR/modules/<name>/ самостоятельно. Насколько я понимаю, это не только неправильно, но и чрезвычайно опасно и может вызвать серьезные головные боли в будущем! См. ниже.

Обратите внимание, что

git module deinit

является прямым обратным к

git module init

но

git submodule deinit -- module
git rm -- module

также совершенно противоположно

git submodule add -- URL module
git submodule update --init --recursive -- module

потому что некоторые команды в основном должны делать больше, чем просто одну вещь:

• git submodule deinit -- module
  • (1) updates .git/config
• git rm
  • (2) removes the files of the module
  • (3) тем самым рекурсивно удаляет подмодули подмодуля
  • (4) обновления .gitmodules
• git submodule add
  • pulls in the data to .git/modules/NAME/
  • (1) делает git submodule init, поэтому обновляет .git/config
  • (2) выполняет git submodule update, поэтому нерекурсивно проверяет модуль
  • (4) обновления .gitmodules
• git submodule update --init --recursive -- module
  • pulls in further data if needed
  • (3) рекурсивно проверяет подмодули подмодуля

Это не может быть полностью симметричным, так как сохранять его строго симметричным не имеет особого смысла. Больше двух команд просто не нужно. Также «извлечение данных» подразумевается, потому что оно вам нужно, но удаление кэшированной информации не выполняется, потому что это вообще не нужно и может стереть ценные данные.

Это действительно озадачивает новичков, но в основном это хорошо: git просто делает то, что очевидно, и делает это правильно, и даже не пытается делать больше. git - это инструмент, который должен выполнять надежную работу, а не просто очередной «Eierlegende Wollmilchsau» («Eierlegende Wollmilchsau» переводится для меня как «злая версия швейцарского армейского ножа»).

Так что я понимаю жалобы людей, которые говорят: «Почему бы мне не сделать git очевидную вещь». Это потому, что «очевидное» здесь зависит от точки зрения. Надежность в любой ситуации гораздо важнее. Следовательно, то, что для вас очевидно, часто не является правильным во всех возможных технических ситуациях. Пожалуйста, помните: AFAICS git следует техническому, а не социальному пути. (Отсюда и хитрое название: git)

Если это не удается

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

• Ваш git слишком старый. Тогда используйте более новый git. (См. Ниже, как это сделать.)
• У вас есть незафиксированные данные, и вы можете их потерять. Тогда лучше сначала зафиксируйте их.
• Ваш подмодуль нечист в git clean смысле. Затем сначала очистите свой подмодуль с помощью этой команды. (См. ниже.)
• Вы сделали что-то в прошлом, что не поддерживается git. Тогда вы перейдете на темную сторону, и все станет уродливым и сложным. (Возможно, это исправит использование другой машины.)
• Возможно, есть другие способы потерпеть неудачу, о которых я не знаю (я просто какой-то git опытный пользователь).

Возможные исправления приведены ниже.

Используйте более новую git

Если ваша машина слишком старая, в вашем git нет submodule deinit. Если вы не хотите (или можете) обновлять свой git, просто используйте другой компьютер с более новым git! git предназначен для полного распространения, поэтому вы можете использовать другой git для выполнения работы:

• workhorse:~/path/to/worktree$ git status --porcelain не должен ничего выводить! Если это так, сначала очистите вещи!
• workhorse:~/path/to/worktree$ ssh account@othermachine
• othermachine:~$ git clone --recursive me@workhorse path/to/worktree/.git TMPWORK && cd TMPWORK
• Теперь займемся подмодулем
• othermachine:~/TMPWORK$ git commit . -m . && exit
• workhorse:~/path/to/worktree$ git fetch account@othermachine:TMPWORK/.git
• workhorse:~/path/to/worktree$ git merge --ff-only FETCH_HEAD. Если это не сработает, используйте git reset --soft FETCH_HEAD
• Теперь убирайте вещи, пока git status снова не станет чистым. Вы можете это сделать, потому что уже успели очистить его, благодаря первому шагу.

Это othermachine может быть какая-то виртуальная машина или какой-нибудь Ubuntu WSL под Windows, что угодно. Даже chroot (но я предполагаю, что вы не root, потому что если вы root, вам будет проще перейти на более новую git).

Обратите внимание: если вы не можете ssh войти, существует масса способов транспортировать git репозитории. Вы можете скопировать свое рабочее дерево на какой-нибудь USB-накопитель (включая каталог .git) и клонировать с него. Клонируйте копию, чтобы снова получить чистую информацию. Это может быть PITA, если ваши подмодули недоступны напрямую с другой машины. Но и для этого есть решение:

git config --add url.NEWURLPREFIX.insteadOf ORIGINALURLPREFIX

Вы можете использовать это умножение, и оно сохраняется в $HOME/.gitconfig. Что-то вроде

git config --add 'url./mnt/usb/repo/.insteadof' https://github.com/

перезаписывает URL-адреса, например

https://github.com/XXX/YYY.git

в

/mnt/usb/repo/XXX/YYY.git

Это легко, если вы начнете привыкать к таким мощным git функциям.

Очистите вещи в первую очередь

Очистка вручную - это хорошо, потому что таким образом вы, возможно, обнаружите некоторые вещи, о которых забыли.

• Если git жалуется на несохраненный материал, зафиксируйте его и отправьте в безопасное место.
• Если git жалуется на остатки, git status и git clean -ixfd ваш друг.
• Постарайтесь как можно дольше воздерживаться от вариантов rm и deinit. Варианты (например, -f) для git хороши, если вы профессионал. Но когда вы пришли сюда, вы, вероятно, не так уж опытны в области submodule. Так что лучше перестраховаться, чем сожалеть.

Пример:

$ git status --porcelain
 M two
$ git submodule deinit two
error: the following file has local modifications:
    two
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'two' contains local modifications; use '-f' to discard them
$ cd two
$ git submodule deinit --all
error: the following file has local modifications:
    md5chk
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'md5chk' contains local modifications; use '-f' to discard them
$ cd md5chk
$ git submodule deinit --all
error: the following file has local modifications:
    tino
(use --cached to keep the file, or -f to force removal)
fatal: Submodule work tree 'tino' contains local modifications; use '-f' to discard them
$ cd tino
$ git status --porcelain
?? NEW
$ git clean -i -f -d
Would remove the following item:
  NEW
*** Commands ***
    1: clean                2: filter by pattern    3: select by numbers    4: ask each
    5: quit                 6: help
What now> 1
Removing NEW
$ cd ../../..
$ git status --porcelain
$ git submodule deinit two
Cleared directory 'two'
Submodule 'someunusedname' (https://github.com/hilbix/src.git) unregistered for path 'two'

Видите ли, на submodule deinit не требуется -f. Если все чисто, в git clean смысле. Также обратите внимание, что git clean -x не требуется. Это означает, что git submodule deinit безоговорочно удаляет неотслеживаемые файлы, которые игнорируются. Обычно это именно то, что вам нужно, но не забывайте об этом. Иногда игнорируемые файлы могут быть ценными, например, кэшированные данные, на повторный расчет которых уходит от нескольких часов до дней.

Почему никогда не удалять $GIT_DIR/modules/<name>/?

Вероятно, люди хотят удалить кешированный репозиторий, потому что боятся столкнуться с проблемой позже. Это правда, но столкновение с этой «проблемой» - правильный способ ее решить! Поскольку исправить это легко и сделать правильно, вы сможете жить долго и счастливо. Это позволяет избежать более громоздких проблем, чем когда вы удаляете данные самостоятельно.

Пример:

mkdir tmptest &&
cd tmptest &&
git init &&
git submodule add https://github.com/hilbix/empty.git two &&
git commit -m . &&
git submodule deinit two &&
git rm two &&
git commit -m . &&
git submodule add https://github.com/hilbix/src.git two

Последняя строка выводит следующую ошибку:

A git directory for 'two' is found locally with remote(s):
  origin    https://github.com/hilbix/empty.git
If you want to reuse this local git directory instead of cloning again from
  https://github.com/hilbix/src.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.

Почему эта ошибка? Поскольку .git/modules/two/ ранее заполнялся из https://github.com/hilbix/empty.git, а теперь должен быть повторно заполнен чем-то еще, а именно https://github.com/hilbix/src.git. Вы не увидите этого, если повторно заполните его с https://github.com/hilbix/empty.git

Что делать сейчас? Что ж, делай в точности как сказали! Используйте --name someunusedname

git submodule add --name someunusedname https://github.com/hilbix/src.git two

.gitmodules тогда выглядит как

[submodule "someunusedname"]
    path = two
    url = https://github.com/hilbix/src.git

ls -1p .git/modules/ дает

someunusedname/
two/

Таким образом, в будущем вы можете переключать ветки / коммит вперед и назад и никогда больше не столкнетесь с какими-либо проблемами из-за two/ наличия двух разных (и, возможно, несовместимых) исходных репозиториев. И самое лучшее: вы также храните оба кешированных локально.

• Это верно не только для вас. Это также верно для всех остальных, использующих ваш репозиторий.
• И вы не потеряете историю. Если вы забыли установить самую последнюю версию старого подмодуля, вы можете ввести локальную копию и сделать это позже. Обратите внимание, что довольно часто кто-то забывает подтолкнуть некоторые подмодули (потому что это PITA для новичков, пока они не привыкнут к git).

Однако, если вы удалите кэшированный каталог, обе разные проверки будут сталкиваться друг с другом, потому что вы не будете использовать параметры --name, верно? Поэтому каждый раз, когда вы выполняете оформление заказа, вам, возможно, придется снова и снова удалять каталог .git/modules/<module>/. Это чрезвычайно громоздко и затрудняет использование чего-то вроде git bisect.

Таким образом, существует очень техническая причина сохранить этот каталог модуля в качестве заполнителя. Люди, которые рекомендуют удалить что-то ниже .git/modules/, либо не знают, либо забывают сказать вам, что это делает практически невозможным использование таких мощных функций, как git bisect, если это пересекает несовместимость таких подмодулей.

Еще одна причина указана выше. Посмотрите на ls. Что ты там видишь?

Ну, второй вариант модуля two/ не под .git/modules/two/, он под .git/modules/someunusedname/! Так что такие вещи, как git rm $module; rm -f .git/module/$module, совершенно неправильны! Вы должны проконсультироваться с module/.git или .gitmodules, чтобы найти то, что нужно удалить!

Так что не только большинство других ответов попадают в эту опасную ловушку, даже очень популярные расширения git имели эту ошибку < / a> (теперь там исправлено)! Так что лучше держите в руках каталог .git/, если вы не совсем то, что делаете!

А с философской точки зрения стирать историю всегда неправильно! Как обычно, кроме квантовой механики, но это совсем другое.

К вашему сведению, вы, наверное, догадались: hilbix - это моя учетная запись GitHub.

С git v2.7.4 простые 3 шага работали нормально.

git submodule deinit -f -- a/submodule    
git rm -f a/submodule
git commit

Если вы только что добавили подмодуль, и, например, вы просто добавили не тот подмодуль или добавили его не в то место, просто выполните git stash, а затем удалите папку. Предполагается, что добавление подмодуля - единственное, что вы сделали в недавнем репо.

Подводя итог, вот что вам следует сделать:

Установите переменную path_to_submodule (без косой черты в конце):

path_to_submodule=path/to/submodule

Удалите соответствующую строку из файла .gitmodules:

git config -f .gitmodules --remove-section submodule.$path_to_submodule

Удалите соответствующий раздел из .git / config

git config -f .git/config --remove-section submodule.$path_to_submodule

Деактивировать и удалить $ path_to_submodule только из индекса (для предотвращения потери информации)

git rm --cached $path_to_submodule

Отслеживайте изменения, внесенные в .gitmodules

git add .gitmodules

Зафиксируйте суперпроект

git commit -m "Remove submodule submodule_name"

Удалите теперь неотслеживаемые файлы подмодулей

rm -rf $path_to_submodule

rm -rf .git/modules/$path_to_submodule

См. Также: Альтернативные рекомендации

Я создал сценарий bash, чтобы упростить процесс удаления. Он также проверяет, есть ли изменения в репо, оставшиеся несохраненными, и запрашивает подтверждение. Он был протестирован на os x. Было бы интересно узнать, работает ли он так же, как и в обычных дистрибутивах Linux:

https://gist.github.com/fabifrank/cdc7e67fd194333760b060835ac0172f

В последнем git требуется всего 4 операции для удаления подмодуля git.

• Удалить соответствующую запись в .gitmodules
• Изменения стадии git add .gitmodules
• Удалите каталог подмодуля git rm --cached <path_to_submodule>
• Зафиксировать git commit -m "Removed submodule xxx"

Если вам нужно сделать это с помощью однострочной команды с помощью сценария bash, как показано ниже:

$ cd /path/to/your/repo && /bin/bash $HOME/remove_submodule.sh /path/to/the/submodule

Создайте файл сценария bash в каталоге $HOME с именем, например, remove_submodule.sh:

#!/bin/bash

git config -f .gitmodules --remove-section submodule.$1
git config -f .git/config --remove-section submodule.$1
git rm --cached $1
git add .gitmodules
git commit -m "Remove submodule in $1"
rm -rf $1
rm -rf .git/modules/$1
git push origin $(git rev-parse --abbrev-ref HEAD) --force --quiet

• A submodule can be deleted by running git rm <submodule path> && git commit. This can be undone using git revert.
  • The deletion removes the superproject's tracking data, which are both the gitlink entry and the section in the .gitmodules file.
  • Рабочий каталог подмодуля удаляется из файловой системы, но каталог Git сохраняется, чтобы можно было проверять прошлые коммиты, не требуя выборки из другого репозитория.
• Чтобы полностью удалить подмодуль, дополнительно удалите $GIT_DIR/modules/<name>/.

Источник: git help submodules

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

'fatal: not removing 'demolibapp' recursively without -r'

1. demolibapp - это имя моего подмодуля, который я хочу удалить
2. Подмодуль git deinit demolibapp
3. git rm --cached demolibapp -r
4. rm -rf .git / модули / demolibapp
5. git add --all
6. git commit -m удаление лишних подмодулей
7. git push
8. rm -rf demolibapp

Удаление подмодуля git

Чтобы удалить подмодуль git, необходимо выполнить ниже 4 шага.

1. Удалите соответствующую запись в .gitmodules файле. Запись может быть такой, как указано ниже

[submodule "path_to_submodule"]
    path = path_to_submodule
    url = url_path_to_submodule

2. Изменения стадии git add .gitmodules
3. Удалите каталог подмодулей git rm --cached <path_to_submodule>.
4. Зафиксируйте git commit -m "Removed submodule xxx" и нажмите.

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

5. Удалите соответствующую запись в .git/config файле. Запись может быть такой, как указано ниже

[submodule "path_to_submodule"]
    url = url_path_to_submodule

6. Do rm -rf .git/modules/path_to_submodule

Эти 5-й и 6-й шаги не создают никаких изменений, требующих фиксации.