我正试图将子模块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
$
EDIT1
在类似的环境中使用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
EDIT2 - self注释
global config
$ git config --global --list
user.email=you@example.com
http.sslverify=false
local config—为什么有2?这是地方性的还是全球性的?
$ git config --list | grep ssl
http.sslverify=false
http.sslverify=false
这可能是原因:[PATCH]子模块:stop saniztizing配置选项- 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 ...