Question

Recently in git 1.7.8, a change was introduced to “handle” submodules differently than before – https://lkml.org/lkml/2011/12/2/316

When populating a new submodule directory with “git submodule init”,
the $GIT_DIR metainformation directory for submodules is created inside
$GIT_DIR/modules// directory of the superproject and referenced
via the gitfile mechanism. This is to make it possible to switch
between commits in the superproject that has and does not have the
submodule in the tree without re-cloning.

So now, instead of cloning the submodule into the specified directory, instead a .git file is created and within it is this:

$ cat .git
gitdir: ../../../../.git/modules/app/src/emberlabs/openflame

My problem: I’m on git 1.7.9, and I need the files of the cloned submodule to be in my local clone exactly where I expect them, instead of where git dictates they should be – as was the behavior before git 1.7.8, where I could ls the submodule’s clone directory and find all files of the cloned commit present.

Any suggestions or ideas on how to…well, re-achieve this?

Answer 1

Found a solution to this.

Editing the file the {$project_root}/.git/modules/{$submodule_path}/.git/config and removing the worktree line under [core], and copying over the entire .git directory from {$project_root}/.git/modules/{$submodule_path}/ into the submodule’s actual location (after deleting the .git file where the submodule was) and then running git checkout -f {$branch} seems to have pulled all files back up. Not entirely sure that it is a full solution however.