You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As protocol URI transformation is not predictable across different platforms like github, a relative URI should be preferred. Thus e.g. package managers can easily check out submodules via the same protocol that is used for checking out the main repo.
(solves https://bugs.gentoo.org/show_bug.cgi?id=568156)
Comment by Earnestly Tuesday Dec 22, 2015 at 20:44 GMT
This smells like a package manager/package build system problem; with something like PKGBUILDs this is easily handled with:
# It is merely coincidence that the submodule is from the same# github user, but this could be from anywhere.
source=('git+https://github.com/Cloudef/wlc''git+https://github.com/Cloudef/chck')
# And in the prepare/post-build function:prepare() {
cd wlc
git submodule init
git config submodule.lib/chck.url "$srcdir"/chck
git submodule update lib/chck
}
I'm not sure how it works in Gentoo but usually packages have a policy of "do not download during the build" and "do not build during the install".
Comment by mgorny Thursday Dec 24, 2015 at 08:20 GMT
@Cloudef, I don't understand the problem you are referring to. This affects only the clone URI, and is relatively to the remote URI. So if you git clone git@github.com:... the original repository, the submodule will also be fetched from github via SSH.
Comment by Cloudef Monday Jan 04, 2016 at 14:32 GMT
This actually breaks your fork, since it tries to clone chck from your github git path, but does not exist there. I think it's better to use git config to specify the submodule url manually for the specific cases.
Comment by mgorny Monday Jan 04, 2016 at 19:26 GMT
I'd dare say fork is a specific case, while just cloning the upstream repo is a generic case which should be accounted for. IOW, person doing git clone https://github.com/Cloudef/wlc would expect submodules to work out of the box, independently of firewalls.
Activity
WLCIssuesBot commentedon May 3, 2017
Tuesday Dec 22, 2015 at 20:44 GMT
This smells like a package manager/package build system problem; with something like
PKGBUILDs this is easily handled with:I'm not sure how it works in Gentoo but usually packages have a policy of "do not download during the build" and "do not build during the install".
WLCIssuesBot commentedon May 3, 2017
Tuesday Dec 22, 2015 at 20:50 GMT
This breaks git submodules completely when ../chck.git is not available. Effectively breaking in-source builds which are useful for development.
WLCIssuesBot commentedon May 3, 2017
Thursday Dec 24, 2015 at 08:20 GMT
@Cloudef, I don't understand the problem you are referring to. This affects only the clone URI, and is relatively to the remote URI. So if you
git clone git@github.com:...the original repository, the submodule will also be fetched from github via SSH.WLCIssuesBot commentedon May 3, 2017
Monday Jan 04, 2016 at 07:34 GMT
All right, I did not know relative urls are relative to the actual remote. This makes sense then. I'll test this later.
WLCIssuesBot commentedon May 3, 2017
Monday Jan 04, 2016 at 14:32 GMT
This actually breaks your fork, since it tries to clone chck from your github git path, but does not exist there. I think it's better to use git config to specify the submodule url manually for the specific cases.
WLCIssuesBot commentedon May 3, 2017
Monday Jan 04, 2016 at 19:26 GMT
I'd dare say fork is a specific case, while just cloning the upstream repo is a generic case which should be accounted for. IOW, person doing
git clone https://github.com/Cloudef/wlcwould expect submodules to work out of the box, independently of firewalls.