Re: url.<base>.insteadOf vs. submodules
- From
Jeff King <peff@peff.net>
- Date
- Feb 21, 2017, 23:40 UTC
- Message-ID
- <20170221234037.ga44u3birwd5whab@sigill.intra.peff.net>
- In-Reply-To
- <CAGZ79kby-UhUqci9Mgdhw+wvS5Y39=Q7AmCrWaTMWbcZPNT6Dw@mail.gmail.com>
On Tue, Feb 21, 2017 at 03:16:27PM -0800, Stefan Beller wrote:
Show 7 quoted lines
> > 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).
Show 5 quoted lines
> 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@benjaminfuchs.de/ > 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.
Show 5 quoted lines
> 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.
Show 7 quoted lines
> > 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