Как удалить субмодуль Git?

Кстати, есть ли причина, которую я не могу просто сделать git submodule rm whatever?

Начиная с версии 1.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: Об этом говорится в Дэниела Шредера «S ответ , и суммированы 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- в фиксации ead8dbe , 13 февраля 2018)}

git ${wt_prefix:+-C "$wt_prefix"} submodule--helper deinit \
  ${GIT_QUIET:+--quiet} \
  ${prefix:+--prefix "$prefix"} \
  ${force:+--force} \
  ${deinit_all:+--all} "$@"

Через страницу Git Submodule Tutorial :

Для удаления подмодуля вам необходимо:

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.8.5.2, две команды будут делать:

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

Как правильно указал ответ @Mark Cheverton, если вторая строка не используется, даже если вы удалили субмодуль на данный момент, остальная папка .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

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

Подмодуль, клонированный с использованием 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

Простые шаги

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 blah@blah.com: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, возможно, кто-то сделает скрипт для вас.

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

[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 config, и тогда вы можете сделать: git rms path/to/submodule

Подводя итог, вот что вы должны сделать:

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

   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

Если подмодуль был случайно добавлен из-за того, что вы добавили, зафиксировали и отправили папку, которая уже была 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.) Удалите ссылку (без косой черты):

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

Недавно я обнаружил проект 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 следует позаботиться об этом. Будем надеяться, что однажды на вторую часть вопроса ОП можно будет дать положительный ответ (что это можно сделать одной командой).

Но по состоянию на июль 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 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.

project dir:     ~/foo_project/
submodule:       ~/foo_project/lib/asubmodule
- - - - - - - - - - - - - - - - - - - - - - - - -
run:
  1.   cd ~/foo_project
  2.   git rm lib/asubmodule && 
          rm .git/modules/lib/asubmodule && 
            git submodule lib/asubmodule deinit --recursive --force

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

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

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

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

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

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

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

• Если это не работает для вас, см. Ниже.
• Нет вариантов. Ничего опасного. И даже не думай делать больше!
• Протестировано с Debian Buster 2.20.1и Ubuntu 18.042.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) обновления .git/config
• git rm
  • (2) удаляет файлы модуля
  • (3) тем самым рекурсивно удаляет подмодули подмодуля
  • (4) обновления .gitmodules
• git submodule add
  • вытягивает данные в .git/modules/NAME/
  • (1) делает git submodule init, поэтому обновления.git/config
  • (2) делает git submodule update, поэтому, нерекурсивно проверяет модуль
  • (4) обновления .gitmodules
• git submodule update --init --recursive -- module
  • тянет в дальнейших данных, если это необходимо
  • (3) рекурсивно проверяет подмодули подмодуля

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

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

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

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

Команды выше могут не работать из-за следующего:

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

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

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

Если Ваш аппарат слишком стар , нет submodule deinitв вашем git. Если вы не хотите (или можете) обновить свой 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, что угодно. Даже a 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 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'

Понимаете, в этом нет -fнеобходимости submodule deinit. Если все чисто, в некотором 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расширения имели эту ошибку ( теперь она исправлена )! Так что лучше держите руки в .git/справочнике, если не совсем точно, что вы делаете!

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

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

Подводя итог, вот что вы должны сделать:

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

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

Смотрите также: Альтернативные направляющие линии

Это легко:

1. Удалить раздел из .gitmodules
2. Вызов: git add .gitmodules
3. Вызов: git submodule deinit <path to submodule>
4. Вызов: git rm <path to submodule>
5. Совершить и нажать

Вам придется удалить файлы модуля в вашем проекте вручную.

Я создал скрипт 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именем ie 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

• Подмодуль можно удалить, запустив git rm <submodule path> && git commit. Это можно отменить с помощью git revert.
  • При удалении удаляются данные отслеживания суперпроекта, которые являются одновременно записью gitlink и разделом в .gitmodulesфайле.
  • Рабочий каталог подмодуля удаляется из файловой системы, но каталог Git сохраняется, поскольку он позволяет извлекать прошлые коммиты, не требуя извлечения из другого репозитория.
• Чтобы полностью удалить подмодуль, дополнительно удалите вручную$GIT_DIR/modules/<name>/ .

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

Удаление подмодуля 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. Делать rm -rf .git/modules/path_to_submodule

Эти 5-й и 6-й этапы не создают никаких изменений, которые необходимо зафиксировать.