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?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With