From: Jeff King <peff@peff.net>
To: Stefan Beller <sbeller@google.com>
Cc: Toolforger <toolforger@durchholz.org>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: url.<base>.insteadOf vs. submodules
Date: Tue, 21 Feb 2017 18:00:29 -0500 [thread overview]
Message-ID: <20170221230029.cs36tjwpsw2opuwp@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGZ79kZgMbEZy7hoA+VxsKdKBavt59SmC1c6FpDdgrW2GKMHvQ@mail.gmail.com>
On Tue, Feb 21, 2017 at 10:19:38AM -0800, Stefan Beller wrote:
> 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.
> 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
next prev parent reply other threads:[~2017-02-21 23:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-19 21:12 url.<base>.insteadOf vs. submodules Toolforger
2017-02-20 9:01 ` Jeff King
2017-02-20 20:31 ` Toolforger
2017-02-20 20:52 ` Jeff King
2017-02-21 5:11 ` Toolforger
2017-02-21 7:06 ` Jeff King
2017-02-21 18:19 ` Stefan Beller
2017-02-21 23:00 ` Jeff King [this message]
2017-02-21 23:16 ` Stefan Beller
2017-02-21 23:37 ` Junio C Hamano
2017-02-21 23:59 ` Junio C Hamano
2017-02-22 0:07 ` Stefan Beller
2017-02-22 2:59 ` Junio C Hamano
2017-02-22 14:00 ` Jon Loeliger
2017-02-22 17:36 ` Junio C Hamano
2017-02-22 18:57 ` Jeff King
2017-02-22 19:11 ` Stefan Beller
2017-02-21 23:40 ` Jeff King
2017-02-22 0:10 ` Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170221230029.cs36tjwpsw2opuwp@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=sbeller@google.com \
--cc=toolforger@durchholz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).