Moritz Angermann
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 https://gitlab.haskell.org/ghc/ghc (cd ghc && git remote add angerman https://gitlab.haskell.org/angerman/ghc) (cd ghc && git fetch --all) (cd ghc/libraries/bytestring && git remote add angerman https://github.com/angerman/bytestring && git fetch --all) (cd ghc/libraries/unix && git remote add angerman https://github.com/angerman/unix && 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 gitlab.haskell.org/ghc/packages/.... This ensures that CI will work for contributors making non-submodule changes in their GHC forks. Cheers, - Ben