我正在尝试将子模块myapp
添加到我的admin
目录中,其中有两个是gits。但我一直在SSL certificate problem
。我已经完成git config http.sslVerify false
尝试让它发挥作用(但我不完全确定为什么这应该有所帮助,当我想要推向主人git push -u origin master
时它有效。)任何想法?
$ pwd
/c/Users/UserName/dir/admin
$ git submodule add ../myapp/
Cloning into 'myapp'...
fatal: unable to access 'https://myserver.com/gogs/user1/myapp/': SSL certificate problem: unable to get local issuer certificate
Clone of 'https://myserver.com/gogs/user1/myapp' into submodule path 'myapp' failed
$ git config --list |grep ssl
http.sslverify=false
$
使用ssh在类似的环境中再次尝试,但访问权限有问题。 有什么想法吗?
$ git submodule add ssh:../../lte_data_day_summary/
Cloning into 'sceal/lte_data_day_summary'...
ssh: Could not resolve hostname ssh: Temporary failure in name resolution
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Clone of 'ssh:../../lte_data_day_summary/' into submodule path 'sceal/lte_data_day_summary' failed
$ pwd
/c/Users/User Name/dir1/dir2/sceal
全局配置
$ git config --global --list
user.email=you@example.com
http.sslverify=false
本地配置 - 为什么有2个?这是本地的还是全球性的?
$ git config --list | grep ssl
http.sslverify=false
http.sslverify=false
答案 0 :(得分:0)
这可能是原因:[PATCH] submodule: stop sanitizing config options - Jeff King
The point of having a whitelist of command-line config
options to pass to submodules was two-fold:
1. It prevented obvious nonsense like using core.worktree
for multiple repos.
2. It could prevent surprise when the user did not mean
for the options to leak to the submodules (e.g.,
http.sslverify=false).
For case 1, the answer is mostly "if it hurts, don't do
that". For case 2, we can note that any such example has a
matching inverted surprise (e.g., a user who meant
http.sslverify=true to apply everywhere, but it didn't).
为了避免将它们传递给子模块并导致意外的结果,可能会删除该配置(例如克隆未经验证的证书可验证HTTPS子模块)。一种解决方法是将GIT_SSL_NO_VERIFY
环境变量设置为git submodule
命令:
# Set the environment variable is sufficient, no content is necessary
GIT_SSL_NO_VERIFY= git submodule add ...