Jak usunąć submoduł Git?

Nawiasem mówiąc, czy istnieje powód, dla którego nie mogę tego zrobić git submodule rm whatever?

Od git1.8.3 (22 kwietnia 2013 r.) :

Po wyrażeniu zainteresowania tym modułem za pomocą „ submodule init” nie było już sposobu na porcelanowe powiedzenie „Nie jestem już zainteresowany tym submodułem ”.
„ submodule deinit” jest na to sposobem.

Proces usuwania również wykorzystuje git rm(od git1.8.5 października 2013).

Podsumowanie

3-etapowy proces usuwania wyglądałby wtedy:

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

Wyjaśnienie

rm -rf: To jest wspomniane w Daniela Schroeder „s odpowiedzi i podsumować Eonil w komentarzach :

Pozostawia to .git/modules/<path-to-submodule>/bez zmian.
Więc jeśli raz usuniesz submoduł za pomocą tej metody i ponownie dodasz je ponownie, nie będzie to możliwe, ponieważ repozytorium już zostało uszkodzone.

git rm: Zobacz zatwierdzenie 95c16418 :

Obecnie użycie „ git rm” w podmodule usuwa drzewo pracy submodułu z drzewa superprojektu i gitlink z indeksu.
Ale sekcja podmodułu .gitmodulespozostała nietknięta, co jest pozostałością po usuniętym teraz podmodule i może drażnić użytkowników (w przeciwieństwie do ustawienia w .git/config, musi to pozostać przypomnienie, że użytkownik wykazał zainteresowanie tym podmodułem, więc zostanie on ponownie wypełniony później po wyrejestrowaniu starszego zatwierdzenia).

Pozwól „ git rm” pomóc użytkownikowi, nie tylko usuwając submoduł z drzewa roboczego, ale także usuwając submodule.<submodule name>sekcję „ ” z .gitmodulespliku i wykonując oba etapy.

git submodule deinit: Wynika z tej łatki :

Za pomocą „ git submodule init” użytkownik jest w stanie powiedzieć gitowi, że dba o jedną lub więcej podmodułów i chce, aby został wypełniony przy następnym wywołaniu „ git submodule update”.
Ale obecnie nie ma łatwego sposobu, aby powiedzieć gitowi, że nie dba już o submoduł i chce pozbyć się lokalnego drzewa pracy (chyba że użytkownik wie dużo o wewnętrznych modułach i usunie ustawienie „ submodule.$name.url” .git/configz pracy drzewo).

Pomóż tym użytkownikom, udostępniając deinitpolecenie „ ”.
Spowoduje to usunięcie całej submodule.<name>sekcji .git/configdla danego podmodułu ( lub wszystkich tych, które zostały zainicjowane, jeśli .podano „ ”).
Niepowodzenie, jeśli bieżące drzewo robocze zawiera modyfikacje, chyba że jest wymuszone.
Złóż skargę, gdy dla podmodułu podanego w wierszu poleceń nie można znaleźć ustawienia adresu URL .git/config, ale mimo to nie zawiedzie.

Dba o to, jeśli kroki (de) inicjalizacji ( .git/configi .git/modules/xxx)

Od git1.8.5 git rmdba również o:

• ' add' krok, który rejestruje adres URL submodułu w .gitmodulespliku: należy go usunąć.
• specjalny wpis submodułu (jak ilustruje to pytanie ): git rm usuwa go z indeksu:
  git rm --cached path_to_submodule(bez ukośnika końcowego)
  Spowoduje to usunięcie tego katalogu zapisanego w indeksie specjalnym trybem „160000”, oznaczając go jako katalog główny submodułu .

Jeśli zapomnisz ten ostatni krok i spróbujesz dodać podmoduł jako zwykły katalog, otrzymasz komunikat o błędzie:

git add mysubmodule/file.txt 
Path 'mysubmodule/file.txt' is in submodule 'mysubmodule'

Uwaga: od wersji Git 2.17 (Q2 2018) deinit submodule git nie jest już skryptem powłoki.
Jest to wywołanie funkcji C.

Zobacz zatwierdzenie 2e61273 , zatwierdzenie 1342476 (14 stycznia 2018 r.) Przez Prathamesh Chavan ( pratham-pc) .
^{(Połączone przez Junio ​​C Hamano - gitster- w commit ead8dbe , 13 lutego 2018)}

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

Za pośrednictwem strony Git Submodule Tutorial :

Aby usunąć submoduł, musisz:

1. Usuń odpowiednią sekcję z .gitmodulespliku.
2. Dokonaj .gitmoduleszmian:
   git add .gitmodules
3. Usuń odpowiednią sekcję z .git/config.
4. Usuń pliki submodułu z działającego drzewa i indeksu:
   git rm --cached path_to_submodule(bez końcowego ukośnika).
5. Usuń .gitkatalog submodułu :
   rm -rf .git/modules/path_to_submodule
6. Zatwierdź zmiany:
   git commit -m "Removed submodule <name>"
7. Usuń nieśledzone pliki submodułów:
   rm -rf path_to_submodule

Zobacz także : alternatywne kroki poniżej .

Tylko uwaga. Od wersji git 1.8.5.2 będą wykonywane dwie komendy:

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

Jak słusznie wskazała odpowiedź @Mark Cheverton, jeśli druga linia nie jest używana, nawet jeśli na razie usunąłeś submoduł, pozostały folder .git / modules / the_submodule zapobiegnie dodaniu lub zastąpieniu tego samego submodułu w przyszłości . Ponadto, jak wspomniano @VonC, git rmwykona większość zadań w submodule.

- Aktualizacja (07.05.2017) -

Dla wyjaśnienia the_submodulejest względna ścieżka submodułu wewnątrz projektu. Na przykład, subdir/my_submodulejeśli podmoduł znajduje się w podkatalogu subdir.

Jak wskazano poprawnie w komentarzach i innych odpowiedziach , dwa polecenia (chociaż funkcjonalnie wystarczające do usunięcia submodułu), pozostawiają ślad w [submodule "the_submodule"]sekcji .git/config(od lipca 2017 r.), Które można usunąć za pomocą trzeciego polecenia:

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

Większość odpowiedzi na to pytanie jest nieaktualna, niepełna lub niepotrzebnie złożona.

Podmoduł sklonowany przy użyciu git 1.7.8 lub nowszego pozostawi co najwyżej cztery ślady w twoim lokalnym repozytorium. Proces usuwania tych czterech śladów zapewnia trzy poniższe polecenia:

# 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

Proste kroki

1. Usuń wpisy konfiguracji:
   git config -f .git/config --remove-section submodule.$submodulename
git config -f .gitmodules --remove-section submodule.$submodulename
2. Usuń katalog z indeksu:
   git rm --cached $submodulepath
3. Popełnić
4. Usuń nieużywane pliki:
   rm -rf $submodulepath
rm -rf .git/modules/$submodulename

Uwaga: $submodulepath nie zawiera początkowych ani końcowych ukośników.

tło

Kiedy to zrobisz git submodule add, dodaje to tylko .gitmodules, ale kiedy to zrobisz git submodule init, dodaje się do .git/config.

Jeśli więc chcesz usunąć moduły, ale możesz je szybko przywrócić, wykonaj następujące czynności:

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

Dobrym pomysłem jest zrobienie git rebase HEADnajpierw i git commit na końcu, jeśli umieścisz to w skrypcie.

Zobacz także odpowiedź na pytanie Czy mogę cofnąć wypełnianie podmoduła Git? .

Oprócz zaleceń musiałem też rm -Rf .git/modules/path/to/submodulemóc dodać nowy podmoduł o tej samej nazwie (w moim przypadku widelec zastępowałem oryginalnym)

Aby usunąć submoduł dodany za pomocą:

git submodule add blah@blah.com:repos/blah.git lib/blah

Biegać:

git rm lib/blah

Otóż ​​to.

W przypadku starszych wersji git (około ~ 1.8.5) użyj:

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

Musisz usunąć wpis w .gitmodulesoraz .git/configi usunąć katalog modułu z historii:

git rm --cached path/to/submodule

Jeśli napiszesz na liście mailowej gita, prawdopodobnie ktoś zrobi dla ciebie skrypt powłoki.

Możesz użyć aliasu, aby zautomatyzować rozwiązania dostarczane przez inne osoby:

[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"

Umieść to w swojej konfiguracji git, a następnie możesz: git rms path/to/submodule

Podsumowując, oto co powinieneś zrobić:

1. Ustaw path_to_submodulevar (bez końcowego ukośnika):

   path_to_submodule=path/to/submodule

2. Usuń odpowiedni wiersz z pliku .gitmodules:

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

3. Usuń odpowiednią sekcję z .git / config

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

4. Usuń scenę i usuń $ path_to_submodule tylko z indeksu (aby zapobiec utracie informacji)

   git rm --cached $path_to_submodule

5. Śledź zmiany wprowadzone w .gitmodules

   git add .gitmodules

6. Zatwierdź superprojekt

   git commit -m "Remove submodule submodule_name"

7. Usuń nieśledzone pliki submodułów

   rm -rf $path_to_submodule

   rm -rf .git/modules/$path_to_submodule

Jeśli ten podmoduł został przypadkowo dodany, ponieważ dodałeś, zatwierdziłeś i przekazałeś folder, który był już repozytorium Git (zawarty .git), nie będziesz miał .gitmodulespliku do edycji ani niczego w nim .git/config. W takim przypadku wszystko czego potrzebujesz to:

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

FWIW , również usunąłem .gitfolder przed wykonaniem git add.

Uważam, że deinitdziała dla mnie dobrze:

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

Z git docs :

deinit

Wyrejestruj podane podmoduły, tj. Usuń całą submodule.$name sekcję z .git / config wraz z ich drzewem pracy.

Po eksperymentowaniu ze wszystkimi różnymi odpowiedziami na tej stronie znalazłem rozwiązanie:

#!/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

Przywraca to dokładnie ten sam stan, co przed dodaniem submodułu. Możesz od razu dodać submoduł, co nie było możliwe przy większości odpowiedzi tutaj.

git submodule add $giturl test
aboveScript test

To pozostawia czystą kasę bez żadnych zmian do zatwierdzenia.

Zostało to przetestowane z:

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

To, co obecnie robię, grudzień 2012 r. (Łączy większość tych odpowiedzi):

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}"

Oto co zrobiłem:

1.) Usuń odpowiednią sekcję z pliku .gitmodules. Możesz użyć poniższego polecenia:

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

2.) Wprowadź .gitmoduleszmiany

git add .gitmodules

3.) Usuń odpowiednią sekcję z .git/config. Możesz użyć poniższego polecenia:

git submodule deinit -f "submodule_name"

4.) Usuń gitlink (bez końcowego ukośnika):

git rm --cached path_to_submodule

5.) Oczyść .git/modules:

rm -rf .git/modules/path_to_submodule

6.) Zobowiązanie:

git commit -m "Removed submodule <name>"

7.) Usuń nieśledzone pliki submodułów

rm -rf path_to_submodule

Niedawno odkryłem projekt git, który zawiera wiele przydatnych poleceń związanych z git: https://github.com/visionmedia/git-extras

Zainstaluj i wpisz:

git-delete-submodule submodule

Potem wszystko się kończy. Katalog submodułów zostanie usunięty z repozytorium i nadal będzie istniał w systemie plików. Następnie można popełnić zmianę takiego: git commit -am "Remove the submodule".

Musiałem pójść krokami Johna Douthata o krok dalej cddo katalogu submodułu, a następnie usunąć repozytorium Git:

cd submodule
rm -fr .git

Następnie mógłbym zatwierdzić pliki jako część nadrzędnego repozytorium Git bez starego odwołania do submodułu.

Oto 4 kroki, które uznałem za konieczne lub przydatne (najpierw najważniejsze):

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

W teorii , git rmw kroku 1 powinien dbać o niego. Mamy nadzieję, że pewnego dnia na drugą część pytania OP można odpowiedzieć pozytywnie (że można to zrobić za pomocą jednego polecenia).

Ale od lipca 2017 r. Krok 2 jest konieczny do usunięcia danych, w .git/modules/przeciwnym razie nie będzie można np. Ponownie dodać submodułu w przyszłości.

Prawdopodobnie możesz wykonać powyższe dwa kroki dla git 1.8.5+, jak zauważono w odpowiedzi Tinlyx , ponieważ wszystkie git submodulepolecenia wydają się działać.

Krok 3 usuwa sekcję dla the_submodulepliku .git/config. Należy to zrobić dla kompletności. (Wpis może powodować problemy dla starszych wersji git, ale nie mam go do przetestowania).

W tym celu większość odpowiedzi sugeruje użycie git submodule deinit. Uważam, że jest to bardziej jednoznaczne i mniej mylące w użyciu git config -f .git/config --remove-section. Według dokumentacji git submodule , git deinit:

Wyrejestruj podane podmoduły ... Jeśli naprawdę chcesz usunąć submoduł z repozytorium i zatwierdzić, użyj zamiast tego git-rm [1] .

Na koniec, jeśli tego nie zrobisz git commit, możesz / możesz otrzymać błąd podczas wykonywania git submodule summary(od git 2.7):

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

Jest to niezależne od tego, czy wykonasz kroki 2 czy 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

Właśnie znalazłem ukryty plik .submodule (zapomniałem dokładnej nazwy), ma on listę ... możesz w ten sposób usunąć je indywidualnie. Właśnie go miałem, więc go usunąłem. Proste, ale może zepsuć Gita, ponieważ nie wiem, czy coś jest związane z submodułem. Na razie wydaje się w porządku, oprócz zwykłego problemu z aktualizacją libetpan, ale (mam nadzieję), że nie ma to związku.

Zauważono, że nikt nie opublikował ręcznego kasowania, więc dodano

W przypadku gita 2.17 i nowszych jest po prostu

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

Jeśli właśnie dodałeś podmoduł i na przykład po prostu dodałeś niewłaściwy podmoduł lub dodałeś go w niewłaściwe miejsce, po prostu git stashusuń folder. Zakłada się, że dodanie podmodułu jest jedyną rzeczą, którą zrobiłeś w ostatnim repo.

Z korzyścią dla czytelnika, tutaj próbuje się to podsumować i podać krok po kroku, jak to zrobić, jeśli rzeczy nie działają zgodnie z oczekiwaniami. Poniżej znajduje się przetestowany i bezpieczny sposób na pozbycie się submodułu dla gitwersji 2.17i wyżej :

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

• Jeśli to nie zadziała, patrz poniżej.
• Brak opcji Nic niebezpiecznego. I nawet nie rozważaj robienia więcej!
• Testowane z Debian Buster 2.20.1i Ubuntu 18.04 2.17.1.
• "$submodule" jest po prostu podkreślenie, gdzie umieścić nazwę, i że musisz uważać na spacje i tym podobne
• Jeśli w systemie Windows zignoruj ​​pierwszy wiersz i zamień "$submodule"na Windows poprawnie podaną ścieżkę do submodułu. (Nie jestem Windows)

Ostrzeżenie!

Nigdy nie dotykaj wnętrza .gitkatalogu! Edycja wewnątrz .gitwchodzi w ciemną stronę. Trzymaj się z dala za wszelką cenę!

I tak, można za to winić git, ponieważ gitw przeszłości brakowało wielu przydatnych rzeczy . Jak właściwy sposób na ponowne usunięcie submodułów.

Myślę, że w dokumentacji jest bardzo niebezpieczna część git submodule. Zaleca się $GIT_DIR/modules/<name>/samemu usunąć . W moim rozumieniu jest to nie tylko błędne, ale także bardzo niebezpieczne i powoduje poważne bóle głowy w przyszłości! Patrz poniżej.

Zauważ, że

git module deinit

jest bezpośrednią odwrotnością do

git module init

ale

git submodule deinit -- module
git rm -- module

jest również odwrotnie

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

ponieważ niektóre polecenia w zasadzie wymagają więcej niż jednej rzeczy:

• git submodule deinit -- module
  • (1) aktualizacje .git/config
• git rm
  • (2) usuwa pliki modułu
  • (3) tym samym rekurencyjnie usuwa submoduły submodułu
  • (4) aktualizacje .gitmodules
• git submodule add
  • ściąga dane do .git/modules/NAME/
  • (1) robi git submodule init, więc aktualizuje.git/config
  • (2) git submodule updatetak więc nierekurencyjnie sprawdza moduł
  • (4) aktualizacje .gitmodules
• git submodule update --init --recursive -- module
  • w razie potrzeby pobiera dalsze dane
  • (3) sprawdza rekurencyjnie submoduły submodułu

Nie może to być w pełni symetryczne, ponieważ zachowanie ścisłej symetryczności nie ma większego sensu. Po prostu nie potrzeba więcej niż dwóch poleceń. Również „pobieranie danych” jest niejawne, ponieważ jest ono potrzebne, ale usuwanie buforowanych informacji nie jest wykonywane, ponieważ nie jest to wcale potrzebne i może wyczyścić cenne dane.

To naprawdę jest zagadką dla początkujących, ale w zasadzie jest dobrą rzeczą: gitpo prostu robi to, co oczywiste, i robi to dobrze, a nawet nie próbuje robić więcej. gitto narzędzie, które musi wykonać niezawodny zawód, zamiast być kolejnym „Eierlegende Wollmilchsau” („Eierlegende Wollmilchsau” tłumaczy dla mnie „złą wersję szwajcarskiego noża wojskowego”).

Rozumiem więc narzekania ludzi, mówiąc: „Dlaczego nie robi gitdla mnie rzeczy oczywistych”. Jest tak, ponieważ „oczywiste” zależy tutaj z punktu widzenia. Niezawodność w każdej sytuacji jest znacznie ważniejsza. Dlatego to, co dla Ciebie oczywiste, często nie jest właściwe we wszystkich możliwych sytuacjach technicznych. Pamiętaj, że: AFAICS gitpodąża ścieżką techniczną, a nie społeczną. (Stąd sprytna nazwa: git)

Jeśli to się nie powiedzie

Powyższe polecenia mogą się nie powieść z powodu:

• Twój gitjest za stary. Następnie użyj nowszego git. (Zobacz poniżej, jak to zrobić).
• Masz nieprzydzielone dane i możesz stracić dane. Więc lepiej najpierw je poproś.
• Twój podmoduł nie jest w pewnym git cleansensie czysty . Następnie najpierw wyczyść swój moduł podrzędny za pomocą tego polecenia. (Patrz poniżej.)
• Zrobiłeś coś w przeszłości, co nie jest wspierane przez git. Jesteś wtedy po ciemnej stronie, a sprawy stają się brzydkie i skomplikowane. (Być może użycie innego komputera to naprawia.)
• Być może istnieje więcej sposobów na porażkę, o których nie wiem (jestem tylko pewnym gitużytkownikiem zaawansowanym).

Możliwe są następujące poprawki.

Użyj nowszej git

Jeśli urządzenie jest zbyt stary, tam nie jest submodule deinitw twojej git. Jeśli nie chcesz (lub możesz) zaktualizować swojego git, skorzystaj z innego komputera z nowszym git! gitjest przeznaczony do pełnej dystrybucji, więc możesz użyć innego, gitaby wykonać zadanie:

• workhorse:~/path/to/worktree$ git status --porcelain nie wolno niczego wydawać! Jeśli tak, najpierw posprzątaj rzeczy!
• workhorse:~/path/to/worktree$ ssh account@othermachine
• othermachine:~$ git clone --recursive me@workhorse path/to/worktree/.git TMPWORK && cd TMPWORK
• Teraz wykonaj czynności związane z submodułem
• 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. Jeśli to nie zadziała, użyjgit reset --soft FETCH_HEAD
• Teraz git statusoczyść rzeczy, aż znów będzie czysty. Jesteś w stanie to zrobić, ponieważ już wcześniej wyczyściłeś go, dzięki pierwszemu krokowi.

Może othermachineto być jakaś maszyna wirtualna lub Ubuntu WSL pod Windows, cokolwiek. Nawet a chroot(ale zakładam, że nie jesteś rootem, ponieważ jeśli tak, rootto łatwiej jest zaktualizować do nowszej wersji git).

Pamiętaj, że jeśli nie możesz sshwejść, istnieje wiele sposobów transportu gitrepozytoriów. Możesz skopiować swój zestaw roboczy na pamięć USB (w tym .gitkatalog) i sklonować z pamięci USB . Sklonuj kopię, aby ponownie uzyskać porządek. Może to być PITA, na wypadek gdyby Twoje podmoduły nie były dostępne bezpośrednio z innej maszyny. Ale jest na to również rozwiązanie:

git config --add url.NEWURLPREFIX.insteadOf ORIGINALURLPREFIX

Możesz użyć tego mnożenia, i to jest zapisane w $HOME/.gitconfig. Coś jak

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

przepisuje adresy URL takie jak

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

w

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

Łatwo jest przyzwyczaić się do gittakich zaawansowanych funkcji.

Najpierw posprzątaj rzeczy

Ręczne czyszczenie jest dobre, ponieważ w ten sposób możesz wykryć niektóre rzeczy, o których zapomniałeś.

• Jeśli git narzeka na niezapisane rzeczy, zatwierdzaj je i pchaj w bezpieczne miejsce.
• Jeśli git narzeka na resztki git statusi git clean -ixfdjest twoim przyjacielem
• Staraj się powstrzymywać od opcji rmi deinittak długo, jak możesz. Opcje (jak -f) gitsą dobre, jeśli jesteś profesjonalistą. Ale kiedy tu przyjechałeś, prawdopodobnie nie jesteś tak doświadczony w submoduleokolicy. Więc lepiej bądź bezpieczny niż przykro.

Przykład:

$ 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'

Widzisz, nie ma takiej -fpotrzeby submodule deinit. W pewnym git cleansensie rzeczy są czyste . Pamiętaj również, że git clean -xnie jest to konieczne. Oznacza to git submodule deinitbezwarunkowe usuwanie nieśledzonych plików, które są ignorowane. Jest to zwykle to, czego chcesz, ale nie zapominaj o tym. Czasami ignorowane pliki mogą być cenne, jak dane w pamięci podręcznej, których ponowne obliczenie zajmuje kilka godzin lub dni.

Dlaczego nigdy nie usuwać $GIT_DIR/modules/<name>/?

Prawdopodobnie ludzie chcą usunąć buforowane repozytorium, ponieważ boją się później napotkać problem. To prawda, ale napotkanie tego „problemu” jest właściwym sposobem na jego rozwiązanie! Ponieważ naprawa jest łatwa i wykonana poprawnie, będziesz mógł żyć długo i szczęśliwie. Pozwala to uniknąć kłopotliwych problemów niż podczas samodzielnego usuwania danych.

Przykład:

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

Ostatni wiersz wyświetla następujący błąd:

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.

Dlaczego ten błąd? Ponieważ .git/modules/two/wcześniej był wypełniany z https://github.com/hilbix/empty.git, a teraz zostanie ponownie wypełniony z czegoś innego, mianowicie https://github.com/hilbix/src.git . Nie zobaczysz tego, jeśli ponownie wypełnisz go z https://github.com/hilbix/empty.git

Co zrobić teraz? Zrób dokładnie to, co powiedziano! Posługiwać się--name someunusedname

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

.gitmodules wtedy wygląda jak

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

ls -1p .git/modules/ daje

someunusedname/
two/

W ten sposób w przyszłości możesz przełączać gałęzie / zatwierdzać do przodu i do tyłu i nigdy więcej nie będziesz mieć kłopotów z powodu two/posiadania dwóch różnych (i prawdopodobnie niekompatybilnych) repozytoriów. A najlepsze jest to, że przechowujesz je w pamięci podręcznej również lokalnie.

• Dotyczy to nie tylko ciebie. Dotyczy to również wszystkich innych korzystających z Twojego repozytorium.
• I nie tracisz historii. Jeśli zapomniałeś wypchnąć najnowszą wersję starego podmodułu, możesz wprowadzić lokalną kopię i zrobić to później. Zauważ, że często zdarza się, że ktoś zapomina pchnąć jakieś podmoduły (ponieważ jest to PITA dla nowoprzybyłych, dopóki się nie przyzwyczai git).

Jeśli jednak usuniesz buforowany katalog, obie różne kasy natkną się na siebie, ponieważ nie użyjesz --nameopcji, prawda? Dlatego za każdym razem, gdy robisz kasę, być może będziesz musiał ciągle usuwać .git/modules/<module>/katalog. Jest to bardzo uciążliwe i utrudnia korzystanie z czegoś takiego git bisect.

Jest więc bardzo techniczny powód, aby zachować ten katalog modułów jako symbol zastępczy. Ludzie, którzy zalecają usunięcie czegoś poniżej, .git/modules/albo nie wiedzą lepiej, albo zapominają powiedzieć, że powoduje to, że potężne funkcje są git bisectprawie niemożliwe do użycia, jeśli powoduje to niezgodność submodułu.

Kolejny powód pokazano powyżej. Spójrz na ls. Co tam widzisz

Cóż, drugi wariant modułu two/nie jest pod .git/modules/two/, jest pod .git/modules/someunusedname/! Takie rzeczy git rm $module; rm -f .git/module/$modulesą całkowicie błędne! Musisz albo skonsultować się, module/.gitalbo .gitmodulesznaleźć właściwą rzecz do usunięcia!

Więc nie tylko większość innych odpowiedzi wpada w tę niebezpieczną pułapkę, nawet bardzo popularne gitrozszerzenia miały ten błąd ( teraz jest tam naprawiony )! Więc lepiej trzymaj ręce w .git/katalogu, jeśli nie dokładnie to, co robisz!

A z filozoficznego punktu widzenia wymazywanie historii zawsze jest złe! Z wyjątkiem mechaniki kwantowej , jak zwykle, ale jest to coś zupełnie innego.

Dla pewnie zgadłeś: hilbix to moje konto GitHub.

Podsumowując, oto co powinieneś zrobić:

Ustaw path_to_submodule var (bez końcowego ukośnika):

path_to_submodule=path/to/submodule

Usuń odpowiedni wiersz z pliku .gitmodules:

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

Usuń odpowiednią sekcję z .git / config

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

Usuń scenę i usuń $ path_to_submodule tylko z indeksu (aby zapobiec utracie informacji)

git rm --cached $path_to_submodule

Śledź zmiany wprowadzone w .gitmodules

git add .gitmodules

Zatwierdź superprojekt

git commit -m "Remove submodule submodule_name"

Usuń nieśledzone pliki submodułów

rm -rf $path_to_submodule

rm -rf .git/modules/$path_to_submodule

Zobacz także: Alternatywne linie pomocnicze

To łatwe:

1. Usuń sekcję z .gitmodules
2. Połączenie: git add .gitmodules
3. Połączenie: git submodule deinit <path to submodule>
4. Połączenie: git rm <path to submodule>
5. Zatwierdź i pchnij

Będziesz musiał ręcznie usunąć pliki modułu z projektu.

Stworzyłem skrypt bash, aby ułatwić proces usuwania. Sprawdza również, czy zmiany nie zostały zapisane w repozytorium i prosi o potwierdzenie. Testowany os xbyłby ciekawie wiedzieć, czy działa tak samo jak w przypadku popularnych dystrybucji Linuksa:

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

W najnowszym git potrzeba tylko 4 operacji, aby usunąć podmoduł git.

• Usuń odpowiedni wpis w .gitmodules
• Zmiany sceniczne git add .gitmodules
• Usuń katalog submodułu git rm --cached <path_to_submodule>
• Zaangażuj się git commit -m "Removed submodule xxx"

Na wypadek, gdybyś musiał to zrobić za pomocą jednego wiersza polecenia ze skryptem bash, jak poniżej:

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

Utwórz plik skryptu bash w katalogu $HOMEo nazwie np . 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

• Podmoduł można usunąć, uruchamiając git rm <submodule path> && git commit. Można to cofnąć za pomocą git revert.
  • Usunięcie usuwa dane śledzenia superprojektu, które są zarówno wpisem gitlink, jak i sekcją .gitmodulespliku.
  • Katalog roboczy podmodułu jest usuwany z systemu plików, ale katalog Git jest przechowywany, ponieważ umożliwia pobranie poprzednich zatwierdzeń bez konieczności pobierania z innego repozytorium.
• Aby całkowicie usunąć submoduł, dodatkowo ręcznie usuń$GIT_DIR/modules/<name>/ .

Źródło: git help submodules

Usuwanie podmodułu git

Aby usunąć gitsubmoduł, potrzebne są 4 kroki.

1. Usuń odpowiedni wpis w .gitmodulespliku. Wpis może być jak wspomniano poniżej

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

2. Zmiany sceniczne git add .gitmodules
3. Usuń katalog submodułu git rm --cached <path_to_submodule>.
4. Zaakceptuj git commit -m "Removed submodule xxx"i pchnij.

Potrzebne są dodatkowe 2 kolejne kroki wymienione poniżej, aby całkowicie wyczyścić submoduł w lokalnej sklonowanej kopii.

5. Usuń odpowiedni wpis w .git/configpliku. Wpis może być jak wspomniano poniżej

[submodule "path_to_submodule"]
    url = url_path_to_submodule

6. Zrobić rm -rf .git/modules/path_to_submodule

Te 5. i 6. kroki nie powodują żadnych zmian, które wymagają zatwierdzenia.