Git how to remove submodule

How to un-submodule a Git submodule?

What are the best practices for un-submoduling a Git submodule, bringing all the code back into the core repository?

13 Answers 13

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

If all you want is to put your submodule code into the main repository, you just need to remove the submodule and re-add the files into the main repo:

If you also want to preserve the history of the submodule, you can do a small trick: “merge” the submodule into the main repository, so that the result will be the same as it was before, except that the submodule files are now in the main repository.

In the main module you will need to do the following:

The resulting repository will look a bit weird: there will be more than one initial commit. But it won’t cause any problems for Git.

It builds on the excellent work by Lucas Jenß, described in his blog post «Integrating a submodule into the parent repository», but automates the entire process and cleans up a few other corner cases.

The latest code will be maintained with bugfixes on github at https://github.com/jeremysears/scripts/blob/master/bin/git-submodule-rewrite, but for the sake of proper stackoverflow answer protocol, I’ve included the solution in its entirety below.

git-submodule-rewrite:

Since git 1.8.5 (Nov 2013) (without keeping the history of the submodule):

Once the removal of the submodule is complete ( deinit and git rm ), you can rename the folder back to its original name and add it to the git repo as a regular folder.

Lots of answers here but all of them seem to be overly complex and likely do not do what you want. I am sure most people want to keep their history.

Start by cloning the parent repo and removing the old submodule.

Now we will add the child repos upstream to the main repo.

The next step assumes that you want to move the files on the merge-prep branch into the same location as the submodule was above although you can easily change the location by changing the file path.

Now you can simply merge your files back into the master branch.

Look around and make sure everything looks good before running git push

It happened to us that we created 2 repositories for 2 projects that were so coupled that didn’t make any sense to have them separated, so we merged them.

I’ll show how to merge the master branches in each first and then I will explain how you can extend this to every branches you got, hope it helps you.

If you got the submodule working, and you want to convert it to a directory in place you can do:

Here we do a clean clone to work. For this process you don’t need to initialize or update the submodules, so just skip it.

After saving the file,

Here we remove the submodule relation completely so we can create bring the other repo to the project in-place.

Here we fetch the submodule repository to merge.

Here we start a merge operation of the 2 repositories, but stop before commit.

Here we send the content of master in the submodule to the directory where it was before prefixing a directory name

Here we complete the procedure doing a commit of the changes in the merge.

After finishing this you can push, and start again with any other branch to merge, just checkout the branch in you repository that will receive the changes and change the branch you bringing in the merge and read-tree operations.

myusuf3 / delete_git_submodule.md

To remove a submodule you need to:

dtelaroli commented Apr 9, 2021 •

Thank you! Saved my day!

DDR0 commented Apr 16, 2021

kevinmsantos commented Apr 26, 2021

Value! Deu certo.

andrp92 commented May 24, 2021

Worked just perfect.! Thanks.!

PingchuanMa commented Jun 14, 2021

sweeha commented Jun 17, 2021 •

sharunspi commented Jun 28, 2021

macagua commented Aug 21, 2021

Thanks you very much, for me work perfect this tip!

cthiebaud commented Aug 26, 2021

Mason-Lin commented Sep 7, 2021

thank you so much!

Aschen commented Sep 10, 2021

Every time I want to remove a submodule, I come back to this Gist and follow the instructions. It’s crazy how difficult it is to work with submodule.
Many thanks!

ccwanggl commented Oct 4, 2021

We should upvote this answer

mayujie commented Oct 12, 2021

I think above can be simplified using following commands. git submodule deinit

Thanks very helpful

dptsolutions commented Oct 22, 2021

We should upvote this answer

For those of us on Windows, here’s the equivalent in Powershell:

lecksfrawen commented Oct 30, 2021

BenjaminWolfe commented Dec 20, 2021

Thank you! Not all heroes wear capes!

berkayyaman commented Dec 23, 2021

wiratana commented Jan 1, 2022

LW-Ho commented Jan 12, 2022

vincent-picaud commented Jan 19, 2022

If you use Magit (under Emacs), go to your project root and then:

you will be asked which submodule you want to remove. That’s it 🙂

Icy-Thought commented Mar 22, 2022 •

If you use Magit (under Emacs), go to your project root and then:

you will be asked which submodule you want to remove. That’s it 🙂

Why? Because I was, oddly enough, unable to find my repository’s submodules by following the steps you had mentioned in your comment.

Git Submodules: Adding, Using, Removing, Updating

I’ve spent a little more than a month working with Git now. I can honestly say that while there are many things that I like about Git, there are just as many things that I personally find to be a pain in the butt.

Submodules specifically have managed to be a thorn in my side on many occasions. While the concept of submodules is simple, figuring out how to actually work with them can be a chore. I say “figuring out” because not everything about working with submodules is well documented. I’ll cover two of the more difficult things to figure out: removing and updating submodules from your repository.

What are Submodules?

The concept of submodules is brilliant. It essentially allows you to attach an external repository inside another repository at a specific path. In order to illustrate the value of submodules, it will probably be helpful for me to explain how I am using them.

My profession is working with WordPress themes. Basically, I develop feature enhancements to the themes. I develop the code for these enhancements in modules that are completely contained in their own folder. This allows for the code to be easily added to other themes and also simplifies code updates/improvements as the code for specific features is consistent across all the themes that use that specific module.

Each theme that we produce is kept in its own Git repository. In addition, I’ve created a separate repository for each one of these feature modules. Rather than actually putting the feature module code directly into the theme repositories, I simply add the needed feature module repositories as submodules.

For example, we have a theme called FlexxBold. FlexxBold currently includes a total of seven submodules: billboard, contact-page-plugin, featured-images, feedburner-widget, file-utility, flexx-layout-editor, and tutorials. Since I’m using submodules, the code can be pulled directly from the relevant submodule repositories rather than requiring me to manually update each individual theme repository.

As I mentioned before, not everything in Git is easy to work with. There are four main functions you will need to understand in order to work with Git submodules. In order, you will need to know how to add, make use of, remove, and update submodules. I’ll cover each of those uses below.

Adding Submodules to a Git Repository

Fortunately, adding a submodule to a git repository is actually quite simple. For example, if I’m in the repository working directory of a new theme called SampleTheme and need to add the billboard repository to the path lib/billboard, I can do so with the following command:

There are three main parts to this command:

Let’s check to see how the repository is doing.

Being able to modify this file later will come in handy later.

All that is left to do now is to commit the changes and then push the commit to a remote system if necessary.

Using Submodules

Having submodules in a repository is great and all, but if I look in my repository, all I have is an empty folder rather than the actual contents of the submodule’s repository. In order to fill in the submodule’s path with the files from the external repository, you must first initialize the submodules and then update them.

Note: This has changed in newer versions of Git. Now the submodule’s repository will be cloned with master checked out. If that repository also has submodules, then your submodule’s submodules will have to be populated by following the steps below from within your project’s submodule directory (confusing yet?).

First, we need to initialize the submodule(s). We can do that with the following command:

Then we need to run the update in order to pull down the files.

Looking in the lib/billboard directory now shows a nice listing of the needed files.

Removing Submodules

What happens if we need to remove a submodule? Maybe I made a mistake. It could also be that the design of the project has changed, and the submodules need to change with it. No problem, I’ll simply run git submodule rm [submodule path] and everything will be great, right?

Unfortunately, this is wrong. Git does not have a built in way to remove submodules. Hopefully this will be resolved in the future, because we now have to do submodule removal manually.

Sticking with the example, we’ll remove the lib/billboard module from SampleTheme. All the instructions will be run from the working directory of the SampleTheme repository. In order, we need to do the following:

Updating Submodules

There is an aspect about submodules that some may not realize when first working with Git submodules. When you add the submodule, the most recent commit of the submodule is stored in the main repository’s index. That means that as the code in the submodule’s repository updates, the same code will still be pulled on the repositories relying on the submodule.

This makes a lot of sense when you consider how your code will have been tested and verified (or at least should be) against a specific version of the submodule code, but the main repository’s code may not work well with new submodule updates before the changes are tested.

Unfortunately, like removing submodules, Git does not make it clear how to update a submodule to a later commit. Fortunately though, it’s not that tough.

Closing Thoughts

I’ve learned a lot in my short time with Git. Expect to see more details about working with Git in the future. I have a series of pitfalls I’ve discovered that I should organize together and post about. I’ve also created some really slick scripts to help me automate numerous things when working with the repositories that I’d like to share.

If there is anything specific you’d like to know about Git, please add a comment or contact me.

Git how to remove submodule

Check your version of git by running

SYNOPSIS

DESCRIPTION

Inspects, updates and manages submodules.

For more information about submodules, see gitsubmodules[7].

COMMANDS

With no arguments, shows the status of existing submodules. Several subcommands are available to perform operations on the submodules.

Add the given repository as a submodule at the given path to the changeset to be committed next to the current project: the current project is termed the «superproject».

The default remote is the remote of the remote-tracking branch of the current branch. If no such remote-tracking branch exists or the HEAD is detached, «origin» is assumed to be the default remote. If the superproject doesn’t have a default remote configured the superproject is its own authoritative upstream and the current working directory is used instead.

The optional argument

is the relative location for the cloned submodule to exist in the superproject. If

is not given, the canonical part of the source repository is used («repo» for «/path/to/repo.git» and «foo» for «host.xz:foo/.git»). If

exists and is already a valid Git repository, then it is staged for commit without cloning. The

If you are only interested in changes of the currently initialized submodules with respect to the commit recorded in the index or the HEAD, git-status[1] and git-diff[1] will provide that information too (and can also report changes to a submodule’s work tree).

arguments limit which submodules will be initialized. If no path is specified and submodule.active has been configured, submodules configured to be active will be initialized, otherwise all submodules are initialized.

See the add subcommand for the definition of default remote.

When the command is run without pathspec, it errors out, instead of deinit-ing everything, to prevent mistakes.

If you really want to remove a submodule from the repository and commit that use git-rm[1] instead. See gitsubmodules[7] for removal options.

the commit recorded in the superproject will be checked out in the submodule on a detached HEAD.

the current branch of the submodule will be rebased onto the commit recorded in the superproject.

the commit recorded in the superproject will be merged into the current branch in the submodule.

the submodule is not updated.

summary [—cached|—files] [(-n|—summary-limit) ] [commit] [—] [

As an example, the command below will show the path and currently checked out commit for each submodule:

A repository that was cloned independently and later added as a submodule or old setups have the submodules git directory inside the submodule instead of embedded into the superprojects git directory.

This command is recursive by default.

OPTIONS

Only print error messages.

This option is only valid for the deinit command. Unregister all submodules in the working tree.

This option is only valid for add, deinit and update commands. When running add, allow adding an otherwise ignored submodule path. When running deinit the submodule working trees will be removed even if they contain local changes. When running update (only effective with the checkout procedure), throw away local changes in submodules when switching to a different commit; and always run a checkout operation in the submodule, even if the commit listed in the index of the containing repository matches the commit checked out in the submodule.

This option is only valid for status and summary commands. These commands typically use the commit found in the submodule HEAD, but with this option, the commit stored in the index is used instead.

This option is only valid for the summary command. This command compares the commit in the index with that in the submodule HEAD when this option is used.

This option is only valid for the summary command. Limit the summary size (number of commits shown in total). Giving 0 will disable the summary; a negative number means unlimited (the default). This limit only applies to modified submodules. The size is always limited to 1 for added/deleted/typechanged submodules.

This option is only valid for the update command. Don’t fetch new objects from the remote site.

This option is only valid for the update command. Initialize all submodules for which «git submodule init» has not been called so far before updating.

This option is only valid for the add command. It sets the submodule’s name to the given string instead of defaulting to its path. The name must be valid as a directory name and may not end with a /.

This option is only valid for add and update commands. These commands sometimes need to clone a remote repository. In this case, this option will be passed to the git-clone[1] command.

This option is only valid for add and update commands. These commands sometimes need to clone a remote repository. In this case, this option will be passed to the git-clone[1] command.

This option is only valid for foreach, update, status and sync commands. Traverse submodules recursively. The operation is performed not only in the submodules of the current repo, but also in any nested submodules inside those submodules (and so on).

This option is valid for add and update commands. Create a shallow clone with a history truncated to the specified number of revisions. See git-clone[1]

This option is only valid for the update command. Clone new submodules in parallel with as many jobs. Defaults to the submodule.fetchJobs option.

Paths to submodule(s). When specified this will restrict the command to only operate on the submodules found at the specified paths. (This argument is required with add).

Git how to remove submodule

Check your version of git by running

SYNOPSIS

DESCRIPTION

A submodule is a repository embedded inside another repository. The submodule has its own history; the repository it is embedded in is called a superproject.

The gitlink entry contains the object name of the commit that the superproject expects the submodule’s working directory to be at.

Submodules can be used for at least two different use cases:

Using another project while maintaining independent history. Submodules allow you to contain the working tree of another project within your own working tree while keeping the history of both projects separate. Also, since submodules are fixed to an arbitrary version, the other project can be independently developed without affecting the superproject, allowing the superproject project to fix itself to new versions only when desired.

Splitting a (logically single) project into multiple repositories and tying them back together. This can be used to overcome current limitations of Git’s implementation to have finer grained access:

Size of the Git repository: In its current form Git scales up poorly for large repositories containing content that is not compressed by delta computation between trees. For example, you can use submodules to hold large binary assets and these repositories can be shallowly cloned such that you do not have a large history locally.

Transfer size: In its current form Git requires the whole working tree present. It does not allow partial trees to be transferred in fetch or clone. If the project you work on consists of multiple repositories tied together as submodules in a superproject, you can avoid fetching the working trees of the repositories you are not interested in.

Access control: By restricting user access to submodules, this can be used to implement read/write policies for different users.

The configuration of submodules

Submodule operations can be configured using the following mechanisms (from highest to lowest precedence):

If the submodule is not yet initialized, then the configuration inside the submodule does not exist yet, so where to obtain the submodule from is configured here for example.

This file mainly serves as the mapping between the name and path of submodules in the superproject, such that the submodule’s Git directory can be located.

If the submodule has never been initialized, this is the only place where submodule configuration is found. It serves as the last fallback to specify where to obtain the submodule from.

FORMS

Submodules can take the following forms:

It is possible to construct these old form repositories manually.