Re: url.<base>.insteadOf vs. submodules

From: Jeff King <peff@peff.net>
Date: Feb 21, 2017, 23:00 UTC
Message-ID: <20170221230029.cs36tjwpsw2opuwp@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kZgMbEZy7hoA+VxsKdKBavt59SmC1c6FpDdgrW2GKMHvQ@mail.gmail.com>

On Tue, Feb 21, 2017 at 10:19:38AM -0800, Stefan Beller wrote:

Show 12 quoted lines

> On Mon, Feb 20, 2017 at 11:06 PM, Jeff King <peff@peff.net> wrote:
> >
> > We'll see if the submodule folks have any ideas on how to implement
> > that.
> >
> 
> So from reading your discussion, the user expectation is to have
> `git submodule {init, update --init, sync}`
> to pay attention to url.<base>.insteadOf when setting up the
> submodule.<name>.URL, such that the modified URL is used for the
> initial clone of the submodule (and hence any subsequent usage within
> the submodule).

Yeah, that was what I was envisioning.

Show 6 quoted lines

> Two caveates:
> 
> * After running `git submodule init`, you change url.<base>.insteadOf
>   in the superproject. How do we need to word the documentation to
>   have users expecting this change doesn't affect submodules?
>   (See above Any vs. "Any except (initialized) submodules")

Good question.

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.

The second half is pretty easy to do (use git_config_from_file on the super-project's $GIT_DIR/config, and pass a callback which filters the keys before passing them along to the real callback).

I'm not sure about the first half (submodules know about their superproject), though.

> * So with the point above the insteadOf config only applies to the
>   init/sync process, (i.e. once in time, ideally).
>   Is that confusing or actually simplifying the submodule workflow?

Not sure. That's why I asked you. :)

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).

-Peff