On Mon, Feb 20, 2017 at 09:31:40PM +0100, Toolforger wrote: > > The submodule operations happen in their own processes, and do not look > > at the config of the parent repo. > > Ah, then we have a docbug. > git help config has this to say: > > url.<base>.insteadOf > Any URL that starts with this value will be rewritten to start, > instead, with <base>. > > The "Any" here is wrong, it would be "any except submodule" (possibly other > exceptions). I'm not sure that "any" is wrong here. Repository-specific config does not cross repository boundaries. That applies to this config value, and to all the others, too (e.g., if you set "diff.renames" in the super-project, it would not have an effect in the submodule). I think if there is a doc bug, it is that the repo boundary between the submodule and the super-project is not made more clear. That said, I do think it would be a useful feature for the super-project to rewrite URLs before handing them off to the submodule. But I do not really work on submodules nor use them myself, so there may be complications. I suppose you could argue that failing to rewrite violates the "any" in the quoted text. It doesn't say when the rewriting occurs, but it is essentially "when the URL is accessed". So the super-project feeds the raw URL to the submodule `git clone`, which then applies any URL rewriting. > > but one workaround is to set the config in ~/.gitconfig. > > No can do - that's under version control. > My personal setup does not belong there I think ;-) I'm not sure I understand. You have a project policy to use certain URLs. But you, the user, want to override that. Why isn't the user-specific config file the right place to put that? (I think there _is_ a mismatch, in that the change is specific not just to your user, but to the repo. So you would not want to rewrite other references to the same URL in other repos. But that does not seem to be your objection). -Peff