You can always peek under the hood to see the Git commands we are using. This is helpful if something strange is happening or if you are just curious. :)
To open the Git output window, run View > Output and select Git from the dropdown.
git submodule deinit <asubmodule>
git rm <asubmodule>
# Note: asubmodule (no trailing slash)
# or, if you want to leave it in your working tree
git rm --cached <asubmodule>
rm -rf .git/modules/<asubmodule>
deinit
Un-register the given submodules, i.e. remove the whole submodule.$name
section from .git/config together with their work tree.
Further calls to git submodule update, git submodule foreach and git submodule sync will skip any unregistered submodules until they are initialized again, so use this command if you don’t want to have a local checkout of the submodule in your work tree anymore.
If you really want to remove a submodule from the repository and commit that use git rminstead.
If --force is specified, the submodule’s work tree will be removed even if it contains local modifications.
I like that you can add git repositories inside eachother using git submodule add but when it’s time to say goodbye to a submodule you need some convoluted statements. So I really wish one day there will be git submodule remove.
Until then, these links will help you to get rid of a git submodule:
Besides the very good point it raises about DVCS (Git, Mercurial and most other DVCSes treat the whole state of the repository as the atom) it also indicates quite a few shortcomings:
most people hardly ever need the full history to be off-line
having the full history means repositories get huge in size, including your off-line clone
pseudo-solutions for huge repository sizes – like git-LFS or git-annex – are a no-go because now you loose atomicity
huge repositories in file or commit counts make them slow, especially when the trees are deep
splitting up repositories isn’t a good idea either because again: you loose atomicity
all DVCS are hard, not just git, because they are distributed and full of features
the workflow for submitting pull requests is quite a bit longer than submitting a patch, even though merging in a DVCS can be hard too (despite atomicity which does help a lot for DVCS systems)
I see many other advantages of DVCS systems (for instance that you only need to locally have the branches you are interested in, way better tooling for DVCS systems, ditto for sites hosting DVCS), but it always a good thing to know the weak spots of what you are working with.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Time to experiment with [WayBack] Gitless: a simple version control system built on top of http://gitless.com/:
…
Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a “porcelain” of Git), you can always fall back on Git.