make submodule URI relative

[hashashini]

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)

[Earnestly]

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".

[Cloudef]

This breaks git submodules completely when ../chck.git is not available. Effectively breaking in-source builds which are useful for development.

[mgorny]

@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.

[Cloudef]

All right, I did not know relative urls are relative to the actual remote. This makes sense then. I'll test this later.

[Cloudef]

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.

[mgorny]

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.