On Tue, Feb 21, 2017 at 03:16:27PM -0800, Stefan Beller 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. Yeah, that was the "first half" that I said was hard. :) You could rationalize it under the fact that they _are_ independent repos; we're just adding a new config source. Arguably it could be a feature for any repository embedded inside the working tree of another, submodule or not, to consider the outer repository as a (limited) source of config. But there are probably a lot of irritating corner cases with the whole concept unless we apply a strict whitelist of keys (e.g., you probably don't want remote.* to be propagated). And as the recent GIT_CONFIG_PARAMETERS whitelist showed, that approach ended up confusing and annoying. So maybe the whole thing is insane, and the right answer is that config values should go into ~/.gitconfig. And we may need better tools there for limiting that global config to certain parts of the tree (like Duy's conditional include thing). > Though I do not know if this is actually a good assumption. > e.g. "[PATCH v2] git-prompt.sh: add submodule indicator" > https://public-inbox.org/git/1486075892-20676-2-git-send-email-email@xxxxxxxxxxxxxxxx/ > really had trouble in the first version to nail down how to tell you are in > a submodule, but people want to know that. Right, I think it's an interesting thing to know, but I agree there are probably a lot of corner cases. > Maybe we need to change that fundamental assumption. > So a more sophisticated way (thinking long term here) would be > to include the superprojects config file (with exceptions), and that > config file has more priority than e.g. the ~/.gitconfig file, but less > than the submodules own $GIT_DIR/config file. Yeah, that priority matches what I had been thinking. > > One other caveat: I'm not sure if we do insteadOf recursively, but it > > may be surprising to the child "git clone" that we've already applied > > the insteadOf rewriting (especially if the rules are coming from > > ~/.gitconfig and may be applied twice). > > When a rule is having effect twice the rule sounds broken. (the outcome > ought to be sufficiently different from the original?) If you have: url.bar.insteadOf=foo url.baz.insteadOf=bar do we convert "foo" to "baz"? If so, then I think applying the rules again shouldn't matter. But if we don't, and only do a single level, then having the caller rewrite the URL before it hands it to "git clone" means we may end up unexpectedly doing two levels of rewriting. -Peff