Stefan Beller <sbeller@xxxxxxxxxx> writes: >> 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. ;) The name that is recorded in the project history "Stefan Beller" matters and the project cares about it, when the commit created in that repository is pulled (or exported and imported via the e-mail to "git am" route). But what name you have configured in your repository's .git/config, or the presense of your particular repository for that matter, is much less significant (and that applies to my primary working area as well). The point is that the project and a particular clone of it are entities at conceptually different levels. >> 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" ? My gut feeling is that we should do the selective/filtered include Peff mentioned when a repository is known to be used as a submodule of somebody else.