How do I remove a Git submodule?
By the way, is there a reason I can't simply do
git submodule rm whatever
?
Since git1.8.3 (April 22d, 2013):
There was no Porcelain way to say "I no longer am interested in this submodule", once you express your interest in a submodule with "
git submodule init
".
"git submodule deinit
" is the way to do so.
The deletion process also uses git rm
(since git1.8.5 October 2013).
The 3-steps removal process would then be:
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
: This is mentioned in Daniel Schroeder's answer, and summarized by Eonil in the comments:
This leaves
.git/modules/<path-to-submodule>/
unchanged.
So if you once delete a submodule with this method and re-add them again, it will not be possible because repository already been corrupted.
git rm
: See commit 95c16418:
Currently using "
git rm
" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index.
But the submodule's section in.gitmodules
is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in.git/config
, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out).
Let "
git rm
" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>
" section from the.gitmodules
file and stage both.
git submodule deinit
: It stems from this patch:
With "
git submodule init
" the user is able to tell git they care about one or more submodules and wants to have it populated on the next call to "git submodule update
".
But currently there is no easy way they can tell git they do not care about a submodule anymore and wants to get rid of the local work tree (unless the user knows a lot about submodule internals and removes the "submodule.$name.url
" setting from.git/config
together with the work tree himself).
Help those users by providing a '
deinit
' command.
This removes the wholesubmodule.<name>
section from.git/config
either for the given submodule(s) (or for all those which have been initialized if '.
' is given).
Fail if the current work tree contains modifications unless forced.
Complain when for a submodule given on the command line the url setting can't be found in.git/config
, but nonetheless don't fail.
This takes care if the (de)initialization steps (.git/config
and .git/modules/xxx
)
Since git1.8.5, the git rm
takes also care of the:
add
' step which records the url of a submodule in the .gitmodules
file: it is need to removed for you.git rm --cached path_to_submodule
(no trailing slash)If you forget that last step, and try to add what was a submodule as a regular directory, you would get error message like:
git add mysubmodule/file.txt
Path 'mysubmodule/file.txt' is in submodule 'mysubmodule'
Note: since Git 2.17 (Q2 2018), git submodule deinit is no longer a shell script.
It is a call to a C function.
See commit 2e61273, commit 1342476 (14 Jan 2018) by Prathamesh Chavan (pratham-pc
).
(Merged by Junio C Hamano -- gitster
-- in commit ead8dbe, 13 Feb 2018)
git ${wt_prefix:+-C "$wt_prefix"} submodule--helper deinit \
${GIT_QUIET:+--quiet} \
${prefix:+--prefix "$prefix"} \
${force:+--force} \
${deinit_all:+--all} "$@"
Via the page Git Submodule Tutorial:
To remove a submodule you need to:
.gitmodules
file..gitmodules
changes:git add .gitmodules
.git/config
.git rm --cached path_to_submodule
(no trailing slash)..git
directory:rm -rf .git/modules/path_to_submodule
git commit -m "Removed submodule <name>"
rm -rf path_to_submodule
See also: alternative steps below.
The majority of answers to this question are outdated, incomplete, or unnecessarily complex.
A submodule cloned using git 1.7.8 or newer will leave at most four traces of itself in your local repo. The process for removing those four traces is given by the three commands below:
# 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
Just a note. Since git 1.8.5.2, two commands will do:
git rm -r the_submodule
rm -rf .git/modules/the_submodule
As @Mark Cheverton's answer correctly pointed out, if the second line isn't used, even if you removed the submodule for now, the remnant .git/modules/the_submodule folder will prevent the same submodule from being added back or replaced in the future. Also, as @VonC mentioned, git rm
will do most of the job on a submodule.
--Update (07/05/2017)--
Just to clarify, the_submodule
is the relative path of the submodule inside the project. For example, it's subdir/my_submodule
if the submodule is inside a subdirectory subdir
.
As pointed out correctly in the comments and other answers, the two commands (although functionally sufficient to remove a submodule), do leave a trace in the [submodule "the_submodule"]
section of .git/config
(as of July 2017), which can be removed using a third command:
git config -f .git/config --remove-section submodule.the_submodule 2> /dev/null
Simple steps
git config -f .git/config --remove-section submodule.$submodulename
git config -f .gitmodules --remove-section submodule.$submodulename
git rm --cached $submodulepath
rm -rf $submodulepath
rm -rf .git/modules/$submodulename
Please note: $submodulepath
doesn't contain leading or trailing slashes.
Background
When you do git submodule add
, it only adds it to .gitmodules
, but
once you did git submodule init
, it added to .git/config
.
So if you wish to remove the modules, but be able to restore it quickly, then do just this:
git rm --cached $submodulepath
git config -f .git/config --remove-section submodule.$submodulepath
It is a good idea to do git rebase HEAD
first and git commit
at the end, if you put this in a script.
Also have a look at an answer to Can I unpopulate a Git submodule?.
To remove a submodule added using:
git submodule add [email protected]:repos/blah.git lib/blah
Run:
git rm lib/blah
That's it.
For old versions of git (circa ~1.8.5) use:
git submodule deinit lib/blah
git rm lib/blah
git config -f .gitmodules --remove-section submodule.lib/blah
To summarize, this is what you should do :
Set path_to_submodule
var (no trailing slash):
path_to_submodule=path/to/submodule
Delete the relevant line from the .gitmodules file:
git config -f .gitmodules --remove-section submodule.$path_to_submodule
Delete the relevant section from .git/config
git config -f .git/config --remove-section submodule.$path_to_submodule
Unstage and remove $path_to_submodule only from the index (to prevent losing information)
git rm --cached $path_to_submodule
Track changes made to .gitmodules
git add .gitmodules
Commit the superproject
git commit -m "Remove submodule submodule_name"
Delete the now untracked submodule files
rm -rf $path_to_submodule
rm -rf .git/modules/$path_to_submodule
You can use an alias to automate the solutions provided by others:
[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"
Put that in your git config, and then you can do: git rms path/to/submodule
If the submodule was accidentally added because you added, committed and pushed a folder that was already a Git repository (contained .git
), you won’t have a .gitmodules
file to edit, or anything in .git/config
. In this case all you need is :
git rm --cached subfolder
git add subfolder
git commit -m "Enter message here"
git push
FWIW, I also removed the .git
folder before doing the git add
.
I found deinit
works good for me:
git submodule deinit <submodule-name>
git rm <submodule-name>
From git docs:
deinit
Unregister the given submodules, i.e. remove the whole
submodule.$name
section from .git/config together with their work tree.
After experimenting with all the different answers on this site, I ended up with this solution:
#!/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
This restores the exact same state as before you added the submodule. You can right away add the submodule again, which was not possible with most of the answers here.
git submodule add $giturl test
aboveScript test
This leaves you with a clean checkout with no changes to commit.
This was tested with:
$ git --version
git version 1.9.3 (Apple Git-50)
What I'm currently doing Dec 2012 (combines most of these answers):
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}"
Here is what I did :
1.) Delete the relevant section from the .gitmodules file. You can use below command:
git config -f .gitmodules --remove-section "submodule.submodule_name"
2.) Stage the .gitmodules
changes
git add .gitmodules
3.) Delete the relevant section from .git/config
. You can use below command:
git submodule deinit -f "submodule_name"
4.) Remove the gitlink (no trailing slash):
git rm --cached path_to_submodule
5.) Cleanup the .git/modules
:
rm -rf .git/modules/path_to_submodule
6.) Commit:
git commit -m "Removed submodule <name>"
7.) Delete the now untracked submodule files
rm -rf path_to_submodule
I recently find out a git project which include many useful git related command: https://github.com/visionmedia/git-extras
Install it and type :
git-delete-submodule submodule
Then things are done. The submodule directory will be removed from your repo and still exist in your filesystem. You can then commit the change like: git commit -am "Remove the submodule"
.
Here are the 4 steps that I found necessary or useful (important ones first):
git rm -f the_submodule
rm -rf .git/modules/the_submodule
git config -f .git/config --remove-section submodule.the_submodule
git commit -m "..."
In theory, git rm
in step 1 should take care of it. Hopefully, the second part of OP question can be answered positively one day (that this can be done in one command).
But as of July 2017, step 2 is necessary to remove data in .git/modules/
for otherwise, you can't e.g. add the submodule back in the future.
You can probably get away with the above two steps for git 1.8.5+ as tinlyx's answer noted, as all git submodule
commands seem to work.
Step 3 removes the section for the_submodule
in the file .git/config
. This should be done for completeness. (The entry may cause problems for older git versions, but I don't have one to test).
For this, most answers suggest using git submodule deinit
. I find it more explicit and less confusing to use git config -f .git/config --remove-section
. According to the git-submodule documentation, git deinit
:
Unregister the given submodules ... If you really want to remove a submodule from the repository and commit that use git-rm[1] instead.
Last but not least, if you don't git commit
, you will/may get an error when doing git submodule summary
(as of git 2.7):
fatal: Not a git repository: 'the_submodule/.git'
* the_submodule 73f0d1d...0000000:
This is regardless of whether you do steps 2 or 3.
I just found the .submodule (forgot exact name) hidden file, it has a list... you can erase them individually that way. I just had one, so I deleted it. Simple, but it might mess up Git, since I don't know if anything's attached to the submodule. Seems ok so far, aside from libetpan's usual upgrade issue, but that's (hopefully) unrelated.
Noticed nobody posted manual erasing, so added
For the benefit of the reader, this here tries to sum it up and give a step-by-step guide on how to do it if things do not work as expected. Following is the tested and safe way for git
version 2.17
and above to get rid of a submodule:
submodule="path/to/sub" # no trailing slash!
git submodule deinit -- "$submodule"
git rm -- "$submodule"
2.20.1
and Ubuntu 18.04 2.17.1
."$submodule"
is just to emphasize where to put the name, and that you have to be careful with spaces and the like"$submodule"
with the Windows way of a properly specified path to the submodule. (I am not Windows)Warning!
Never touch the insides of the
.git
directory yourself! Editing inside.git
enters the dark side. Stay away at all cost!And yes, you can blame
git
for this, as many handy things were missing ingit
in the past. Like a proper way to remove submodules again.I think there is a very dangerous part in the documentation of
git submodule
. It recommends to remove$GIT_DIR/modules/<name>/
yourself. In my understanding this is not only plain wrong, it is extremely dangerous and provokes major headaches in future! See below.
Note that
git module deinit
is the direct inverse to
git module init
but
git submodule deinit -- module
git rm -- module
also is quite the inverse to
git submodule add -- URL module
git submodule update --init --recursive -- module
because some commands basically need to do more than just a single thing:
git submodule deinit -- module
.git/config
git rm
.gitmodules
git submodule add
.git/modules/NAME/
git submodule init
, so updates .git/config
git submodule update
, so, nonrecursively checks out the module.gitmodules
git submodule update --init --recursive -- module
This cannot be fully symmetric, as keeping it strictly symmetric does not make much sense. There simply is no need for more than two commands. Also "pulling in the data" is implicit, because you need it, but removing the cached information is not done, because this is not needed at all and might wipe precious data.
This truly is puzzling to newcomers, but basically is a good thing: git
just does the obviously thing and does that right, and does not even try to do more. git
is a tool, which must do a reliable job, instead of being just another "Eierlegende Wollmilchsau" ("Eierlegende Wollmilchsau" translates for me to "some evil version of a Swiss army knife").
So I understand complaints of people, saying "Why doesn't do git
the obvious thing for me". This is because "obvious" here depends from the point of view. Reliability in each and every situation is far more important. Hence what's obvious for you often is not the right thing in all possible technical situations. Please remember that: AFAICS git
follows the technical path, not the social one. (Hence the clever name: git)
The commands above may fail due to following:
git
is too old. Then use a newer git
. (See below how to.)git clean
sense. Then first clean your submodule using that command. (See below.)git
. Then you are on the dark side and things get ugly and complicated. (Perhaps using another machine fixes it.)git
power-user.)Possible fixes follow.
git
If your machine is too old there is no submodule deinit
in your git
. If you do not want (or can) update your git
, then just use another machine with a newer git
! git
is meant to be fully distributed, so you can use another git
to get the job done:
workhorse:~/path/to/worktree$ git status --porcelain
must not output anything! If it does, cleanup things first!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
. If this does not work, use git reset --soft FETCH_HEAD
git status
is clean again. You are able to do so, because you have had it clean before, thanks to the first step.This othermachine
can be some VM, or some Ubuntu WSL under Windows, whatever. Even a chroot
(but I assume that you are non-root, because if you are root
it should be more easy to update to the newer git
).
Note that if you cannot ssh
in, there are trainloads of ways to transport git
repositories. You can copy your worktree on some USB stick (including the .git
directory), and clone from the stick. Clone the copy, just to get things in a clean fashion again. This might be a PITA, in case your submodules are not accessible from othermachine directly. But there is a solution for this, too:
git config --add url.NEWURLPREFIX.insteadOf ORIGINALURLPREFIX
You can use this multiply, and this is saved into $HOME/.gitconfig
. Something like
git config --add 'url./mnt/usb/repo/.insteadof' https://github.com/
rewrites URLs like
https://github.com/XXX/YYY.git
into
/mnt/usb/repo/XXX/YYY.git
It's easy if you start to become accustomed to powerful git
features like this.
Cleaning manually up is good, because this way you perhaps detect some things you forgot about.
git status
and git clean -ixfd
is your friendrm
and deinit
as long as you can. Options (like -f
) for git
are good if you are a Pro. But as you came here, you probably are not so experienced in the submodule
area. So better be safe than sorry.Example:
$ 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'
You see, there is no -f
needed on submodule deinit
. If things are clean, in a git clean
sense. Also note that git clean -x
is not needed. This means git submodule deinit
unconditionally removes untracked files which are ignored. This is usually what you want, but do not forget about it. Sometimes ignored files might be precious, like cached data which takes hours to days to be calculated again.
$GIT_DIR/modules/<name>/
?Probably people want to remove the cached repository, because they are afraid to run into a problem later. This is true, but running into that "problem" is the correct way to solve it! Because the fix is easy, and done right you will be able to live happily ever after. This avoids more cumbersome trouble than when you remove the data yourself.
Example:
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
The last line outputs following error:
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.
Why this error? Because .git/modules/two/
previously was populated from https://github.com/hilbix/empty.git and now shall be re-populated from something else, namely https://github.com/hilbix/src.git. You won't see this if you re-populate it from https://github.com/hilbix/empty.git
What to do now? Well, just do exactly as told! Use --name someunusedname
git submodule add --name someunusedname https://github.com/hilbix/src.git two
.gitmodules
then looks like
[submodule "someunusedname"]
path = two
url = https://github.com/hilbix/src.git
ls -1p .git/modules/
gives
someunusedname/
two/
This way in future you can switch branches/commit forward and backward and will never get into any trouble again, due to two/
having two different (and possibly incompatible) upstream repositories. And the best is: You keep both cached locally, too.
git
).However if you removed the cached directory, both different checkouts will stumble upon each other, because you will not use the --name
options, right? So each time you do the checkout you perhaps have to remove the .git/modules/<module>/
directory again and again. This is extremely cumbersome and makes it hard to use something like git bisect
.
So there is a very technical reason to keep this module directory as a placeholder. People who recommend to remove something below .git/modules/
either do not know better or forget to tell you that this makes powerful features like git bisect
nearly impossible to use if this crosses such a submodule incompatibility.
A further reason is shown above. Look at the ls
. What do you see there?
Well, the 2nd variant of module two/
is not under .git/modules/two/
, it is under .git/modules/someunusedname/
! So things like git rm $module; rm -f .git/module/$module
are totally wrong! You must either consult module/.git
or .gitmodules
to find the right thing to remove!
So not only most other answers fall into this dangerous trap, even very popular git
extensions had this bug (it's now fixed there)! So better keep your hands of the .git/
directory if you do not exactly, what you are doing!
And from the philosophical view, wiping history is always wrong! Except for quantum mechanics, as usual, but this is something completely different.
FYI you probably guessed it: hilbix is my GitHub account.
To summarize, this is what you should do :
Set path_to_submodule var (no trailing slash):
path_to_submodule=path/to/submodule
Delete the relevant line from the .gitmodules file:
git config -f .gitmodules --remove-section submodule.$path_to_submodule
Delete the relevant section from .git/config
git config -f .git/config --remove-section submodule.$path_to_submodule
Unstage and remove $path_to_submodule only from the index (to prevent losing information)
git rm --cached $path_to_submodule
Track changes made to .gitmodules
git add .gitmodules
Commit the superproject
git commit -m "Remove submodule submodule_name"
Delete the now untracked submodule files
rm -rf $path_to_submodule
rm -rf .git/modules/$path_to_submodule
See also : Alternative guide lines
I've created a bash script to ease the removal process. It also checks whether there are changes in the repo left unsaved and asks for confirmation.
It has been tested on os x
would be interesting to know if it works as is on common linux distros as well:
https://gist.github.com/fabifrank/cdc7e67fd194333760b060835ac0172f
In case you need to do it in one line command with bash script as below:
$ cd /path/to/your/repo && /bin/bash $HOME/remove_submodule.sh /path/to/the/submodule
Create bash script file in the $HOME
dir named i.e. 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
. This can be undone using git revert
.
.gitmodules
file. $GIT_DIR/modules/<name>/
.Source: git help submodules
git rm modulename
andrm -rf .git/modules/modulename
– imz -- Ivan Zakharyaschev.git/config
. The accepted answer shows the up-to-date way to fully remove a a submodule. It's also explained more succinctly in this answer: stackoverflow.com/a/36593218/1562138 – fvgs