GitLab forks and submodules

Ben Gamari ben at
Thu Jan 10 17:23:09 UTC 2019

Moritz Angermann <moritz.angermann at> writes:

> Alright let me add some example that is really painful with submodules.
> Say I have a custom ghc fork angerman/ghc, because I really don't want
> to overload CI with all my stupidity and I *know* I'd forget to mark
> every commit with [skip ci] or something.
> Now I need to modify a bunch of submodules as well, say
> - libraries/bytestring
> - libraires/unix
> And next I want to have someone else collaborate on this with me, either
> for testing or contributing or what not.
> So I'm going to give them the following commands to run:
> git clone --recursive
> (cd ghc && git remote add angerman
> (cd ghc && git fetch --all)
> (cd ghc/libraries/bytestring && git remote add angerman && git fetch --all)
> (cd ghc/libraries/unix && git remote add angerman && git fetch --all)
> (cd ghc && git checkout angerman/awesome/sauce)
> (cd ghc && git submodule update --init --recursive)
If you pushed your bytestring and unix changes to your gitlab account
then this wouldn't be necessary. The fact that we use relative paths
would actually work to your advantage.

My current thinking is that the fix-submodules script run by CI should
do the following for each submodule:

 * If the branch has changed the submodule then do nothing (leaving the
   submodule URL as relative; this ensures that a user can push their
   submodule changes to their fork of the submodule on GitLab and things
   will "just work"

 * If the branch has not changed then rewrite the submodule URL to point
   to This ensures that CI will work
   for contributors making non-submodule changes in their GHC forks.


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list