Search code examples
gitgit-submodules

How to remove a submodule going forward, but keep its history (as linked from parent history)?

Say I have a project that has a dependency implemented using git submodule. Now I'm making a change where this dependency is no longer needed. I want to commit a change that works as follows:

  • If anyone checks out this commit or any descendants, the submodule doesn't exist.
  • But if anyone checks out an older commit, or a commit on another branch not merged with this one, the submodule reappears, just as a deleted file would.
  • The submodule's own git database (.git/modules/path/to/submodule) must be preserved as it may contain commits not pushed to a remote.

In other words, I do NOT want to obliterate the submodule as directed by the answers to How do I remove a submodule?. In fact I wrote this question as a counterpoint to clarify that one.[1]

When I get some time I will try some experiments. It may be as simple as git submodule deinit and/or removing its entry from .gitsubmodules. I searched Stack Overflow and found no questions or answers addressing this case specifically. Even the superbly written Mastering Git submodules is not clear about this.

[1]: The many steps required in those answers tells me that such obliteration is not "normal", otherwise git would include a porcelain command that did it all for you. Instead git deinit is provided with very narrow behavior. I think it very intentional.

Solution

  • The git submodule deinit that I documented in 2013 and its associated rm -rf .git/modules/a/submodule both assume the removed submodule was already pushed.

    Submodules were initially introduced to be used as read-only, in order to get other repository content into your repository, without necessarily the intent of modifying them.
    This differs from subtree, where modifications are more naturally expected.

    That being said, yes, if you remove a submodule while having not committed/pushed local changes to said submodule, the end result won't be satisfactory.

    A possible patch idea would be to block/fail the git submodule deinit command when it detects that the submodule current HEAD does not match its own internal remote tracking branch (its own origin/master for instance)