core.sshCommand and url.*.insteadOf for submodules

core.sshCommand and url.*.insteadOf for submodules

[Stefan Schindler]

Hello mailing list,

it seems like that the `core.sshCommand` and `url.*.insteadOf`
configuration settings do not apply to `git submodule update --init`
(and probably related) calls.

Is this intentional?

My scenario is as follows: I use 2 SSH keys for GitHub, for private and
work-related repositories. My default key is my private key. So when I
clone a work repository and try getting the submodules, `git submodule
update --init` fails. This is also the case when setting
`core.sshCommand` and `url.*.insteadOf` (useful for substituting
"github.com" by some ~/.ssh/config'ured host).

Greetings,
Stefan Schindler

Re: core.sshCommand and url.*.insteadOf for submodules

[Stefan Beller]

On Thu, Jan 5, 2017 at 2:09 AM, Stefan Schindler <stsch@boxbox.org> wrote:
> Hello mailing list,
>
> it seems like that the `core.sshCommand` and `url.*.insteadOf`
> configuration settings do not apply to `git submodule update --init`
> (and probably related) calls.
>
> Is this intentional?

The original design of submodules was to have a submodule to be a
standalone repository, such that e.g. its options are read from its own
config file. So the original vision was to decouple the init and clone of the
submodule to allow the user to change the settings:

    git submodule init
    # copies the submodule.<name>.URL from .gitmodules to .git/config
    # user realizes that the URL is not a good idea, such that
    git  config submodule.<name>.url http://${company-mirror}/submodule
    # now the url is fixed so
    git submodule update

I guess it could be a good idea to propagate some settings from the
superproject to the submodules when they are cloned.

>
> My scenario is as follows: I use 2 SSH keys for GitHub, for private and
> work-related repositories. My default key is my private key. So when I
> clone a work repository and try getting the submodules, `git submodule
> update --init` fails. This is also the case when setting
> `core.sshCommand` and `url.*.insteadOf` (useful for substituting
> "github.com" by some ~/.ssh/config'ured host).
>

which is why e.g.
git config --global url.https://github.com/.insteadOf git://github.com/
is not your preferred way here.

There was some discussion a couple of weeks ago, which settings
should be kept when recursing into submodules, Jacob and Jeff cc'd.

> Greetings,
> Stefan Schindler

Re: core.sshCommand and url.*.insteadOf for submodules

[Jeff King]

On Thu, Jan 05, 2017 at 05:53:30AM -0800, Stefan Beller wrote:

> > My scenario is as follows: I use 2 SSH keys for GitHub, for private and
> > work-related repositories. My default key is my private key. So when I
> > clone a work repository and try getting the submodules, `git submodule
> > update --init` fails. This is also the case when setting
> > `core.sshCommand` and `url.*.insteadOf` (useful for substituting
> > "github.com" by some ~/.ssh/config'ured host).
> 
> which is why e.g.
> git config --global url.https://github.com/.insteadOf git://github.com/
> is not your preferred way here.
> 
> There was some discussion a couple of weeks ago, which settings
> should be kept when recursing into submodules, Jacob and Jeff cc'd.

The only discussion I recall was from last May. But that was about "-c"
config on the command-line, and the end decision was that we pass it all
down to submodules, per 89044baa8b (submodule: stop sanitizing config
options, 2016-05-04).

I think the problem here is more about propagating options from the
superproject's repo-level config into the submodules. AFAIK we do not do
that at all, but I may have missed some patches in that area.

Another approach would be conditional config includes based on the repo
path. With the patches discussed in [1], you could do something like:

  git config --global include./path/to/work/repos.path .gitconfig-work
  git config -f ~/.gitconfig-work url.foo.insteadOf bar

-Peff

[1] http://public-inbox.org/git/20160626070617.30211-1-pclouds@gmail.com/

Re: core.sshCommand and url.*.insteadOf for submodules

[Stefan Beller]

On Thu, Jan 5, 2017 at 9:02 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 05, 2017 at 05:53:30AM -0800, Stefan Beller wrote:
>
>> > My scenario is as follows: I use 2 SSH keys for GitHub, for private and
>> > work-related repositories. My default key is my private key. So when I
>> > clone a work repository and try getting the submodules, `git submodule
>> > update --init` fails. This is also the case when setting
>> > `core.sshCommand` and `url.*.insteadOf` (useful for substituting
>> > "github.com" by some ~/.ssh/config'ured host).
>>
>> which is why e.g.
>> git config --global url.https://github.com/.insteadOf git://github.com/
>> is not your preferred way here.
>>
>> There was some discussion a couple of weeks ago, which settings
>> should be kept when recursing into submodules, Jacob and Jeff cc'd.
>
> The only discussion I recall was from last May. But that was about "-c"
> config on the command-line, and the end decision was that we pass it all
> down to submodules, per 89044baa8b (submodule: stop sanitizing config
> options, 2016-05-04).

Oh, yeah that was the difference.

>
> I think the problem here is more about propagating options from the
> superproject's repo-level config into the submodules. AFAIK we do not do
> that at all, but I may have missed some patches in that area.

AFAIK there were no such patches yet.

>
> Another approach would be conditional config includes based on the repo
> path. With the patches discussed in [1], you could do something like:
>
>   git config --global include./path/to/work/repos.path .gitconfig-work
>   git config -f ~/.gitconfig-work url.foo.insteadOf bar

Or maybe we could specialize these patches to allow
includes from specific other repos, i.e. superproject(s) or worktrees.

>
> -Peff
>
> [1] http://public-inbox.org/git/20160626070617.30211-1-pclouds@gmail.com/