Junio C Hamano <gitster@xxxxxxxxx> writes: > So I would think it is entirely reasonable if "git submodule init > sub" that is run in the superproject to initialize "sub" writes > something in "sub/.git" to tell that "sub" is used in the context of > that particular toplevel superproject and customize its behavour > accordingly. Perhaps it may want to add the url.*.insteadOf that is > useful for updating the submodule repository when it does "submodule > init", for example. Of course, "copying" is usually not very desirable, as it invites one of the copies to go stale. An actual implementation may just say "the name of submodule the superproject uses this as is 'foo'". That way, if such a configuration exists, Git can first do cd-up to the root of the working tree, go one level up, verify that it is in a worktree of its superproject, verify that the root of the working tree it came from was indeed bound to the submodule called 'foo' and then do the selective/filtered "config-include" Peff outlined. That would allow superproject to move submodules around (as opposed to recording "this submodule is used at this/path of the superproject" or "the superproject of this submodule is at ../../that/path"), and does not penalize repositories that are not used as submodules of any superproject (because the "cd-up, up, verify and include" won't be done for them). As opposed to "I am used as a submodule" bit, recording the name the superproject uses to call the submodule would also serve as a sanity check measure.