On Tue, Feb 21, 2017 at 3:37 PM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> writes: > >> On Tue, Feb 21, 2017 at 3:00 PM, Jeff King <p...@peff.net> 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.
Oh, I see. For this use case as well as the prompt indicator that I mentioned in the previous email, the most basic question is * Do we have a superproject? [yes/no] The next level of awareness would be * Where is the superproject? [ <relative path?>] These questions may not be interesting for a user (they ought to know about that appliance;) ), but rather for scripted usage, which I think hints at the lack of a submodule plumbing command. Currently we only have git-submodule that is a helper used to somehow cope with submodules. It is used by humans directly and it is listed under "Main porcelain commands" in our man page. Probably we'd also do not want to cram this stuff into the already bloated rev-parse (that has --show-toplevel, which has nothing to do with parsing revs, but as Jeff put it it is the kitchen sink of Git). > > 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. This analogy is less clear to me than the kernel& appliance. When applying it to you (user.name=Junio) that has write powers over the blessed repository, the project cares a lot about you. ;) > 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. Do we want to invent a special value for url.*.insteadOf to mean "look up in superproject, so I don't have to keep a copy that may get stale" ?
