On Tue, Feb 21, 2017 at 10:19:38AM -0800, Stefan Beller wrote:
> On Mon, Feb 20, 2017 at 11:06 PM, Jeff King <p...@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.
> 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
