wlc
wlc copied to clipboard
make submodule URI relative
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)
This smells like a package manager/package build system problem; with something like PKGBUILD
s 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".
This breaks git submodules completely when ../chck.git is not available. Effectively breaking in-source builds which are useful for development.
@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 [email protected]:...
the original repository, the submodule will also be fetched from github via SSH.
All right, I did not know relative urls are relative to the actual remote. This makes sense then. I'll test this later.
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.
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.