{"thread":{"id":"45238","subject":"'git submodules update' ignores credential.helper config of the parent repository","startedAt":"2017-02-27T13:42:08Z","lastAt":"2017-02-28T21:34:37Z","messageCount":7,"participants":["Dmitry Neverov","Stefan Beller","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"312721","messageId":"CAC+L6n0YeX_n_AysCLtBWkA+jPHwg7HmOWq2PLj75byxOZE=qQ@mail.gmail.com","threadId":"45238","inReplyTo":null,"subject":"'git submodules update' ignores credential.helper config of the parent repository","fromName":"Dmitry Neverov","fromEmail":"dmitry.neverov@gmail.com","sentAt":"2017-02-27T13:33:09Z","receivedAt":"2017-02-27T13:42:08Z","isPatch":false,"sender":{"key":"dmitry.neverov@gmail.com","avatar":null},"body":"I'm checking out a repository in a non-interactive environment and\nwould like to disable interactive credential helpers. According to [1]\nit can be done by specifying an empty helper in a local config:\n\n [credential]\n helper =\n\nBut the submodule update command ignores the helper specified in the\nconfig of the parent repository. To reproduce it, fetch a repository\nwith submodules requiring authentication and run:\n\n git submodule init;\n git submodule sync;\n git submodule update;\n\nthe 'git submodule update' runs a default credential helper. The only\nway to disable it is specify helper in command-line:\n\n git -c credential.helper= submodule update\n\nIs it by design?\n\n[1] http://marc.info/?l=git&m=147136396024768&w=2\n"},{"id":"312762","messageId":"CAGZ79ka8saQMKeutE415WxOQ71MnEw1A4uV3b0Pa4gcehx8pdw@mail.gmail.com","threadId":"45238","inReplyTo":"CAC+L6n0YeX_n_AysCLtBWkA+jPHwg7HmOWq2PLj75byxOZE=qQ@mail.gmail.com","subject":"Re: 'git submodules update' ignores credential.helper config of the parent repository","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-27T19:09:12Z","receivedAt":"2017-02-27T19:40:38Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Feb 27, 2017 at 5:33 AM, Dmitry Neverov\n wrote:>\n> git -c credential.helper= submodule update\n>\n> Is it by design?\n\nA similar question came up w.r.t. submodule configuration\nrecently. It is about url..insteadOf[1] that is set\nin the super project and is expected to work in the submodules.\nMore reading on some background there, as it is the very same\nproblem: Which configuration should propagate to the submodules,\nhow do we tell the users and can the user influence if some\narticular settings are propagated?\n\nFor both these settings (url...insteadOf and the credentialHelper)\none might think that they absolutely should be propagated\nto the submodules, but that may not be true; e.g. a submodule\nmight be hosted at a different hosting provider, needing a different\ncredentials setup. (The submodule might be an open source library\nthat you use, which may even require no credentials at all)\n\nSo I think we have to come up with a generic solution to respect\ncertain settings of the superproject instead of e.g. hard coding\ncredential.helper to be looked up in the superproject.\n\nSo the current proposal (in that mentioned thread) is\nto borrow the idea from worktrees that have a similar problem:\nsplit up the config into multiple files and each file applies to\na different worktree or in our case we would have\n(A) a config file that applies to the superproject;\n(B) a config file that applies to both superproject\n and all submodules\n(C) and each submodule has its own config file as well.\n\n---\nFor worktrees these multiple config files sounded like\nthe obvious solution, but I wonder if there was also\nsome bike shedding about other solutions?\n\nI could imagine that we would want to have attributes\nfor specific configuration, e.g.:\n\n--8<--\n[core]\n repositoryformatversion = 0\n filemode = true\n bare = false\n logallrefupdates = true\n[remote \"origin\"]\n url = git://github.com/gitster/git\n fetch = +refs/heads/*:refs/remotes/origin/*\n[attribute \"submodules\"]\n read = true\n# this will be read and respected by submodules as well:\n[url.\"internal-git-miror\"]\n insteadOf = github.com\n[attribute \"submodules\"]\n read = false\n# This (and the beginning of this file) will not be respected\n# by submodules\n[credential]\n helper =\n-->8--\n\nThis would change the semantics of a config file as the attribute for\neach setting depends on the location (was attribute.FOO.read =\n{true, false} read before).\n\nThis would be read-compatible with older versions of Git, and it seems\nas if it were write compatible as well. Just writing a new value with a specifc\nattribute would be interesting to implement.\n\nThanks,\nStefan\n\n\n[1] https://public-inbox.org/git/84fcb0bd-85dc-0142-dd58-47a04eaa7c2b@durchholz.org/\n"},{"id":"312846","messageId":"20170228143710.smbzo6b7wefjc62r@sigill.intra.peff.net","threadId":"45238","inReplyTo":"CAGZ79ka8saQMKeutE415WxOQ71MnEw1A4uV3b0Pa4gcehx8pdw@mail.gmail.com","subject":"Re: 'git submodules update' ignores credential.helper config of the parent repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-28T14:37:10Z","receivedAt":"2017-02-28T14:37:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 27, 2017 at 11:09:12AM -0800, Stefan Beller wrote:\n\n> For worktrees these multiple config files sounded like\n> the obvious solution, but I wonder if there was also\n> some bike shedding about other solutions?\n> \n> I could imagine that we would want to have attributes\n> for specific configuration, e.g.:\n> \n> --8<--\n> [core]\n> repositoryformatversion = 0\n> filemode = true\n> bare = false\n> logallrefupdates = true\n> [remote \"origin\"]\n> url = git://github.com/gitster/git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> [attribute \"submodules\"]\n> read = true\n> # this will be read and respected by submodules as well:\n> [url.\"internal-git-miror\"]\n> insteadOf = github.com\n> [attribute \"submodules\"]\n> read = false\n> # This (and the beginning of this file) will not be respected\n> # by submodules\n> [credential]\n> helper =\n> -->8--\n> \n> This would change the semantics of a config file as the attribute for\n> each setting depends on the location (was attribute.FOO.read =\n> {true, false} read before).\n\nI'm not enthused by this, just because there is a hidden dependency\nbetween attribute.* sections and other ones. They _look_ like regular\nconfig keys, but they really aren't.\n\nI have a feeling that something like this would create unwelcome corner\ncases in the config-writer, which is otherwise does not have to care\nabout which existing section of a file it adds a key to.\n\n-Peff\n"},{"id":"312867","messageId":"CAGZ79kb8F9_9fd9uhfPpHVPQj-zm99qt5Tr=3TUhpe=K6JknEg@mail.gmail.com","threadId":"45238","inReplyTo":"20170228143710.smbzo6b7wefjc62r@sigill.intra.peff.net","subject":"Re: 'git submodules update' ignores credential.helper config of the parent repository","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-28T18:05:24Z","receivedAt":"2017-02-28T18:38:31Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 28, 2017 at 6:37 AM, Jeff King wrote:\n>>\n>> This would change the semantics of a config file as the attribute for\n>> each setting depends on the location (was attribute.FOO.read =\n>> {true, false} read before).\n>\n> I'm not enthused by this, just because there is a hidden dependency\n> between attribute.* sections and other ones. They _look_ like regular\n> config keys, but they really aren't.\n\nTrue.\n\n> I have a feeling that something like this would create unwelcome corner\n> cases in the config-writer, which is otherwise does not have to care\n> about which existing section of a file it adds a key to.\n\nYeah the writer would become a lot more involved, if we're not going\nthe stupid way (add these sections for nearly all keys. that would be\na mess but easy to implement)\n\nSo I guess then we rather settle with multiple config files or a white/blacklist\nof config options to propagate from the superproject to its submodules.\n"},{"id":"312877","messageId":"20170228200821.iojdzntjslwgrzcb@sigill.intra.peff.net","threadId":"45238","inReplyTo":"CAGZ79kb8F9_9fd9uhfPpHVPQj-zm99qt5Tr=3TUhpe=K6JknEg@mail.gmail.com","subject":"Re: 'git submodules update' ignores credential.helper config of the parent repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-28T20:08:22Z","receivedAt":"2017-02-28T20:09:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote:\n\n> > I have a feeling that something like this would create unwelcome corner\n> > cases in the config-writer, which is otherwise does not have to care\n> > about which existing section of a file it adds a key to.\n> \n> Yeah the writer would become a lot more involved, if we're not going\n> the stupid way (add these sections for nearly all keys. that would be\n> a mess but easy to implement)\n> \n> So I guess then we rather settle with multiple config files or a white/blacklist\n> of config options to propagate from the superproject to its submodules.\n\nI'm still open to the idea that we simply improve the documentation to\nmake it clear that per-repo config really is per-repo, and is not shared\nbetween super-projects and submodules. And then something like Duy's\nproposed conditional config lets you set global config that flexibly\ncovers a set of repos.\n\n-Peff\n"},{"id":"312880","messageId":"CAGZ79kZ8ANzjauzJAbPh7m7zYoBrB=ZjgDXHxNb57_H=RYm8cQ@mail.gmail.com","threadId":"45238","inReplyTo":"20170228200821.iojdzntjslwgrzcb@sigill.intra.peff.net","subject":"Re: 'git submodules update' ignores credential.helper config of the parent repository","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-28T20:21:57Z","receivedAt":"2017-02-28T20:29:48Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 28, 2017 at 12:08 PM, Jeff King wrote:\n> On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote:\n>\n>> > I have a feeling that something like this would create unwelcome corner\n>> > cases in the config-writer, which is otherwise does not have to care\n>> > about which existing section of a file it adds a key to.\n>>\n>> Yeah the writer would become a lot more involved, if we're not going\n>> the stupid way (add these sections for nearly all keys. that would be\n>> a mess but easy to implement)\n>>\n>> So I guess then we rather settle with multiple config files or a white/blacklist\n>> of config options to propagate from the superproject to its submodules.\n>\n> I'm still open to the idea that we simply improve the documentation to\n> make it clear that per-repo config really is per-repo, and is not shared\n> between super-projects and submodules. And then something like Duy's\n> proposed conditional config lets you set global config that flexibly\n> covers a set of repos.\n\nHow would the workflow for that look like?\nMy naive thought on that is:\n\n (1) $EDIT .git/config_to_be_included\n (2) $ git config add-config-inclusion .git/config_to_be_included\n (3) $ git submodule foreach git config add-inclusion-config\n.git/config_to_be_included\n\nwhich sounds a bit cumbersome to me.\nSo I guess we'd want some parts of that as part of another command, e.g.\n(3) could be part of (2).\n\n--\nI am also open and willing to document this better; but were would\nwe want to put documentation? Obviously we would not want to put it\nalongside each potentially useful config option to be inherited to\nsubmodules. (that would imply repeating ourselves quite a lot in\nthe config man page).\n\nI guess putting it into \"man gitmodules\" that I was writing tentatively\nwould make sense.\nC.f\nhttps://public-inbox.org/git/20161227234310.13264-4-sbeller@google.com/\n(or search for \"background story\" in your emails)\n\nThanks,\nStefan\n"},{"id":"312903","messageId":"20170228203230.bclfbjp6agufdymr@sigill.intra.peff.net","threadId":"45238","inReplyTo":"CAGZ79kZ8ANzjauzJAbPh7m7zYoBrB=ZjgDXHxNb57_H=RYm8cQ@mail.gmail.com","subject":"Re: 'git submodules update' ignores credential.helper config of the parent repository","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-28T20:32:30Z","receivedAt":"2017-02-28T21:34:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 28, 2017 at 12:21:57PM -0800, Stefan Beller wrote:\n\n> > I'm still open to the idea that we simply improve the documentation to\n> > make it clear that per-repo config really is per-repo, and is not shared\n> > between super-projects and submodules. And then something like Duy's\n> > proposed conditional config lets you set global config that flexibly\n> > covers a set of repos.\n> \n> How would the workflow for that look like?\n> My naive thought on that is:\n> \n> (1) $EDIT .git/config_to_be_included\n> (2) $ git config add-config-inclusion .git/config_to_be_included\n> (3) $ git submodule foreach git config add-inclusion-config\n> .git/config_to_be_included\n> \n> which sounds a bit cumbersome to me.\n> So I guess we'd want some parts of that as part of another command, e.g.\n> (3) could be part of (2).\n\nI think it would be more like:\n\n (1) $EDIT ~/.gitconfig-super\n (2) git config --global \\\n includeIf.gitdir:/path/to/super.path .gitconfig-super\n\nI know that is probably a bit more cumbersome to figure out than\ntreating the super/sub relationship in a special way. But I suspect for\na lot of cases that it actually ends up even better, because the\nsituation is more like:\n\n (1) $EDIT ~/.gitconfig-work\n (2) git config --global includeIf.gitdir:~/work.path .gitconfig-work\n\nand then it covers all of your projects in ~/work, whether they are\nsuper-projects, submodules, or regular repos.\n\n> I am also open and willing to document this better; but were would\n> we want to put documentation? Obviously we would not want to put it\n> alongside each potentially useful config option to be inherited to\n> submodules. (that would imply repeating ourselves quite a lot in\n> the config man page).\n> \n> I guess putting it into \"man gitmodules\" that I was writing tentatively\n> would make sense.\n\nYeah, I think it is worth mentioning in \"gitmodules\", and probably in\ngit-config where we define per-repo config.\n\nIt may also be worth calling it out especially for url.insteadOf, just\nbecause it is not clear there when the URL rewriting happens (it's not\ninsane to think that it happens in the super-project, that just doesn't\nhappen to be how it's implemented).\n\n-Peff\n"}]}