git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Dmitry Neverov <dmitry.neverov@gmail.com>,
	Duy Nguyen <pclouds@gmail.com>, Jeff King <peff@peff.net>,
	Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: 'git submodules update' ignores credential.helper config of the parent repository
Date: Mon, 27 Feb 2017 11:09:12 -0800	[thread overview]
Message-ID: <CAGZ79ka8saQMKeutE415WxOQ71MnEw1A4uV3b0Pa4gcehx8pdw@mail.gmail.com> (raw)
In-Reply-To: <CAC+L6n0YeX_n_AysCLtBWkA+jPHwg7HmOWq2PLj75byxOZE=qQ@mail.gmail.com>

On Mon, Feb 27, 2017 at 5:33 AM, Dmitry Neverov
<dmitry.neverov@gmail.com> wrote:>
>   git -c credential.helper= submodule update
>
> Is it by design?

A similar question came up w.r.t. submodule configuration
recently. It is about url.<URLISH>.insteadOf[1] that is set
in the super project and is expected to work in the submodules.
More reading on some background there, as it is the very same
problem: Which configuration should propagate to the submodules,
how do we tell the users and can the user influence if some
articular settings are propagated?

For both these settings (url...insteadOf and the credentialHelper)
one might think that they absolutely should be propagated
to the submodules, but that may not be true; e.g. a submodule
might be hosted at a different hosting provider, needing a different
credentials setup. (The submodule might be an open source library
that you use, which may even require no credentials at all)

So I think we have to come up with a generic solution to respect
certain settings of the superproject instead of e.g. hard coding
credential.helper to be looked up in the superproject.

So the current proposal (in that mentioned thread) is
to borrow the idea from worktrees that have a similar problem:
split up the config into multiple files and each file applies to
a different worktree or in our case we would have
(A) a config file that applies to the superproject;
(B) a config file that applies to both superproject
     and all submodules
(C) and each submodule has its own config file as well.

---
For worktrees these multiple config files sounded like
the obvious solution, but I wonder if there was also
some bike shedding about other solutions?

I could imagine that we would want to have attributes
for specific configuration, e.g.:

--8<--
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = git://github.com/gitster/git
    fetch = +refs/heads/*:refs/remotes/origin/*
[attribute "submodules"]
    read = true
# this will be read and respected by submodules as well:
[url."internal-git-miror"]
    insteadOf = github.com
[attribute "submodules"]
    read = false
# This (and the beginning of this file) will not be respected
# by submodules
[credential]
    helper =
-->8--

This would change the semantics of a config file as the attribute for
each setting depends on the location (was attribute.FOO.read =
{true, false} read before).

This would be read-compatible with older versions of Git, and it seems
as if it were write compatible as well. Just writing a new value with a specifc
attribute would be interesting to implement.

Thanks,
Stefan


[1] https://public-inbox.org/git/84fcb0bd-85dc-0142-dd58-47a04eaa7c2b@durchholz.org/

  reply	other threads:[~2017-02-27 19:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 13:33 'git submodules update' ignores credential.helper config of the parent repository Dmitry Neverov
2017-02-27 19:09 ` Stefan Beller [this message]
2017-02-28 14:37   ` Jeff King
2017-02-28 18:05     ` Stefan Beller
2017-02-28 20:08       ` Jeff King
2017-02-28 20:21         ` Stefan Beller
2017-02-28 20:32           ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGZ79ka8saQMKeutE415WxOQ71MnEw1A4uV3b0Pa4gcehx8pdw@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=dmitry.neverov@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).