Stefan Beller <sbeller@xxxxxxxxxx> writes: > On Tue, Feb 21, 2017 at 3:00 PM, Jeff King <peff@xxxxxxxx> wrote: > ... >> I guess one answer is that this is the wrong approach entirely, and the >> right one is something like: submodules should understand that they are >> part of a superproject, and respect some whitelisted set of config from >> the superproject .git/config file. > > This would break one of the core assumptions that submodules > are "independent" repos. > > The way of action is a one way street: > * The superproject is aware of the submodule and when you invoke a > command on the superproject, you may mess around with the submodule, > e.g. update/remove it; absorb its git directory. > * The submodule is "just" a repository with weird .git link file and a > respective core.worktree setup. Currently it doesn't know if it is > guided by a superproject. While that is a good discipline to follow, I think you need to differenciate the project that is bound as a submodule to a superproject, and a specific instance of a submodule repository, i.e. a clone of such a project. It is true that the Linux kernel project should *NEVER* know your appliance project only because you happen to use it as a component of your appliance that happens to use the kernel as one of its submodules. But that does not mean your copy of the kernel that sits in your recursive checkout of your appliance project should not know anything about your superproject. This is true even without any submodules. The Git project itself does not even care you are Stefan, but you still can and do add [user] name = "Stefan Beller" to .git/config of your clone of the Git project. A clone of the project may want to know more than the data project itself keeps track of to describe the context in which the particular clone is being used. And .git/config is a good place to keep such pieces of information. 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.